[SOLVED] cache drive, array sleep, read/write


DrJake

Recommended Posts

Hi can't think of a good title thats spot on the issue. So here it goes.

 

I see many people have their unraid setup in such a way that uses SSDs for either cache and/or unassigned devices (UD), as this can greatly increase the perceived speed of the system. There is also an abundant discussion about whether to leave the HDD always spinning, and I believe the consensus is that it is bad to spin up and down too often.

 

So what I would like to do is to work off SSD almost entirely, and have the mechanical drives in the array sleep for most of the day. Then have the mover do its thing daily. So in theory this would only cause the mechanical HDDs to spin up once/twice a day at most. I presume someone has done this before, any comments or suggestions would be appreciated.

 

I do however, have a problem. One of my drives keeps spinning up for some reason. I would like to know what is causing them to spin up. I have 2 always on VMs, 1 running from cache (/domains), 1 running from (UD), and bunch of dockers. The appdata, domains, and system shares are all set to cache=prefer. I've been monitoring the drive that spins up from the dashboard, it gets very few reads/writes, like less than 100 counts/day, it also triggers write to the parity drive as well. The drive has on it the following folders:

  • isos (has VM images)
  • Media (the entire Plex library)
  • Photos (
  • Share (default folder?)
  • Other personal folders

 

My understanding is that the isos folder are not getting written to. I can also confirm that nobody was watching Plex. Does anyone know what's causing the array drive to spin up?  

Link to comment
  • 2 weeks later...
2 hours ago, DrJake said:

woah. more plugins!

 

thx for pointing me in the right direction. Installed the first 2, they seem to fit the bill. Will report back in a few days :)

 go to your Shares tab and click on "compute." This will show you what disk is being occupied by some file on that particular share. 

 

regarding spin up and down: I spent a lot of time worrying about this and I found some post on Servethehome explaining that if your HDD was spinning up like 2 times per day it would take nearly 300 years before it would wear out according to most manufacturer specs. So I let mine spin down after a few hrs. 

Link to comment
8 hours ago, adminmat said:

go to your Shares tab and click on "compute." This will show you what disk is being occupied by some file on that particular share. 

The usual suspects would be appdata, domains, system shares with files on the array, but according to diagnostics these are all completely on cache.

Link to comment
On 1/5/2021 at 2:52 AM, trurl said:

The usual suspects would be appdata, domains, system shares with files on the array, but according to diagnostics these are all completely on cache.

Yes you are correct. 

It was quite revealing after installing the FileActivity plugin. Couple things I've learned:

  • The ISOs folder is opened whenever I start a VM (that was quite contrary to what I thought actually, as the ISO just contains the installation image and the virtio). So think I will have to move this to the cache as well.
  • Most of the file activity before was from the Plex docker. It scanned the entire library periodically. This was turned off in the plex settings. 

I think the above points resolves most of the issue. I've yet to gather enough data on the syncthing docker as I've only recently started using it. Most of the devices in the household (phones, tablets) I think are only syncing at night. But I think the docker itself does keep scanning the folders for updates (not so much applicable for phone backup, but more for shared folders across multiple computers), not sure what the best way is for that.

Link to comment
8 hours ago, DrJake said:

The ISOs folder is opened whenever I start a VM (that was quite contrary to what I thought actually, as the ISO just contains the installation image and the virtio). So think I will have to move this to the cache as well.

This is to be expected as the chances are high that you still have the virtio iso assigned to the VM.   However it is unlikely to be accessing it much after initial startup so leaving it on the main array is not going to adversely affect performance and you may not want to use up the space on your cache.   The alternative is to remove the assignment from the VM configuration which is OK as long as you do not need to access it again for any virtio drivers.

Link to comment

I ended up moving the ISOs folder to cache, only took up like 15Gb of space, which is quite tolerable for me.

 

I've been monitoring the fileactivity for a few days since last reporting here, it has been working very well, I think the disks only needs to spin up when I watch Plex, and at 3.40am for the movers. 

 

Regarding the syncthing problem, I still don't really know how it works, but in my current setup it appears to be not scanning much.

 

In the fileactivity log, I see the following (I don't think it happens daily, as I haven't noticed it before), does anyone know what is creating the .tmp files? if it'll cause the drives to spin up, and how to avoid it?

Jan 10 04:30:13 CREATE => /mnt/disk1/2041296744.tmp
Jan 10 04:30:13 OPEN => /mnt/disk1/2041296744.tmp
Jan 10 04:30:13 OPEN => /mnt/disk1/2041296744.tmp
Jan 10 04:30:13 DELETE => /mnt/disk1/2041296744.tmp

 

Jan 10 04:30:13 CREATE => /mnt/disk2/1694051432.tmp
Jan 10 04:30:13 OPEN => /mnt/disk2/1694051432.tmp
Jan 10 04:30:13 OPEN => /mnt/disk2/1694051432.tmp
Jan 10 04:30:13 DELETE => /mnt/disk2/1694051432.tmp

 

Jan 10 04:30:13 CREATE => /mnt/disk3/2030880645.tmp
Jan 10 04:30:13 OPEN => /mnt/disk3/2030880645.tmp
Jan 10 04:30:13 DELETE => /mnt/disk3/2030880645.tmp
 

Edited by DrJake
Link to comment

Hi all,

 

Thx for all the input. I think this thread can be marked as (resolved now).

 

I still get the odd temp file created and also get some odd opening of selected files on the Plex server at ~2.30am... when i know for sure nobody is accessing the plex server. Anyhow, these don't occur frequently, and don't matter much, as my HDD sleep timer is set a 3h, and these don't cause additional spin ups when mover does its thing.

 

Overall, I found the fileactivity plugin very helpful in isolating the issues.

 

Link to comment
  • JorgeB changed the title to [SOLVED] cache drive, array sleep, read/write
  • 6 months later...
On 1/10/2021 at 12:18 AM, DrJake said:

I ended up moving the ISOs folder to cache, only took up like 15Gb of space, which is quite tolerable for me.

 

I've been monitoring the fileactivity for a few days since last reporting here, it has been working very well, I think the disks only needs to spin up when I watch Plex, and at 3.40am for the movers. 

 

Regarding the syncthing problem, I still don't really know how it works, but in my current setup it appears to be not scanning much.

 

In the fileactivity log, I see the following (I don't think it happens daily, as I haven't noticed it before), does anyone know what is creating the .tmp files? if it'll cause the drives to spin up, and how to avoid it?

Jan 10 04:30:13 CREATE => /mnt/disk1/2041296744.tmp
Jan 10 04:30:13 OPEN => /mnt/disk1/2041296744.tmp
Jan 10 04:30:13 OPEN => /mnt/disk1/2041296744.tmp
Jan 10 04:30:13 DELETE => /mnt/disk1/2041296744.tmp

 

Jan 10 04:30:13 CREATE => /mnt/disk2/1694051432.tmp
Jan 10 04:30:13 OPEN => /mnt/disk2/1694051432.tmp
Jan 10 04:30:13 OPEN => /mnt/disk2/1694051432.tmp
Jan 10 04:30:13 DELETE => /mnt/disk2/1694051432.tmp

 

Jan 10 04:30:13 CREATE => /mnt/disk3/2030880645.tmp
Jan 10 04:30:13 OPEN => /mnt/disk3/2030880645.tmp
Jan 10 04:30:13 DELETE => /mnt/disk3/2030880645.tmp
 

 

Did you ever figure out what was causing this? I'm also seeing it.

Link to comment
On 7/16/2021 at 6:20 AM, CS01-HS said:

 

Did you ever figure out what was causing this? I'm also seeing it.

Hi CS, no, I didn't. After diagnosing the Plex library indexing thing, I monitored the unraid server occasionally, and the disks are sleeping most of the time. So I haven't bothered with the *.tmp files. If you figure it out, please do post :) 

  • Thanks 1
Link to comment
  • 2 weeks later...
On 7/18/2021 at 8:52 PM, DrJake said:

Hi CS, no, I didn't. After diagnosing the Plex library indexing thing, I monitored the unraid server occasionally, and the disks are sleeping most of the time. So I haven't bothered with the *.tmp files. If you figure it out, please do post :) 

 

I believe I found the culprit - Fix Common Problems.

And here's the fix (I'm surprised it's not the default):

1407365105_ErrorsWarningsListedarefromthelastscheduledscan.PressRescantoupdatewiththe.thumb.png.ff28cd5e6e7157ba3a1ca386a78dd20a.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.