Description:

 

Specifying a Disk to be included in the share settings and enabling cache afterwards causes small disk accesses to it even though cache is enabled.

 

How to reproduce:

 

create a share "test", open share settings, pick any one disk (e.g. disk3) in the Included Disk(s), set Use cache disk: to "Prefer".

 

Expected results:

 

reads/writes to share "test" get buffered by the cache, disk3 stays spun down

 

Actual results:

 

reads/writes on share "test" cause disk3 to be accessed which keeps the disk spinning, even though my cache drive had >75% free space.

 

inotifywatch -mr /mnt/disk3 showed:

 

/mnt/disk3/ ACCESS,ISDIR 
/mnt/disk3/ CLOSE_NOWRITE,CLOSE,ISDIR 
/mnt/disk3/ OPEN,ISDIR 
/mnt/disk3/ ACCESS,ISDIR 
/mnt/disk3/ CLOSE_NOWRITE,CLOSE,ISDIR 
/mnt/disk3/ OPEN,ISDIR 
/mnt/disk3/ ACCESS,ISDIR 
/mnt/disk3/ CLOSE_NOWRITE,CLOSE,ISDIR 
/mnt/disk3/ OPEN,ISDIR 
/mnt/disk3/ ACCESS,ISDIR 
/mnt/disk3/ CLOSE_NOWRITE,CLOSE,ISDIR 

(roughly one open/access/close every 10 sec)

 

but lsof /mnt/disk3 showed nothing.

 

edit: after some more testing this seems to happen when disk3 and cache contain a copy of the same folders/data, as was the case with my appdata folder which was in the cache and on disk3.

edit redacted: it seems I was wrong, it still happens when there's no data at all on disk3.

 

Other information:

 

I had an issue with my disk3 not spinning down even though I had no docker containers, exported shares or other programs with access to shares on it.

 

My appdata share was set to "Include Disk: disk3" and "cache: prefer" because I read on here that supposedly this allows the appdata to "overflow" onto the disk3 when the cache drive gets full.

 

However it seems that specifying (e.g. disk3) to be included in a share before turning on the cache will cause random small accesses to /mnt/disk3 even though the cache is enabled.

 

Now that Include Disk: is set to "All" and cache: prefer, disk3 hasn't spun up in over 12 hours.

My suspicion is that this is not a defect and is unRAID checking to see if the file already exists on the array disk before it can decide that it is a new file that should be written to the cache disk.  Do you have the cachedirs plugin installed?  It might help with not spinning up if the relevant directory information for the disk is already cached in memory.

Yes, cache_dirs was installed and working throughout all tests.

 

I thought about whether or not this is intended behaviour and came to the conclusion that it probably is not because when I choose default "All Disks" with "Cache: prefered", no disk spins up.

 

If it was intended behaviour then all disks would have to spin up as the data could be anywhere. Obviously that would be very counterproductive.

 

It's not a huge bug but I spent more time trying to troubleshoot these random spinups (which I suspected to come from a plugin or docker container — so I double and triple checked those...) than I spent setting up unRAID altogether.

Using cache:prefer should cause all files to be moved from the array to cache when mover next runs.  I do not believe it is meant to allow the cache to overflow onto the data disks.  It's prime purpose is to avoid having to change share settings when you later add a physical cache disk having started without one.  I suspect that while cache files exist in both locations that spin-up behavior could well be indeterminate.