I'm looking for some help in identifying what is causing my parity drives to constantly spin up.  Every single one of my shares uses the cache drive and I only enact the mover once per day.  Yet my parity drives are constantly being spun up periodically even though my disk spin down is set for 1hr of idle time.  My data disks spin down and stay down unless the shares are being accessed, but I'm constantly seeing parity drives up during the day.

 

So my question is, what could be causing parity writes to the array when all my shares use cache and none write directly to the array?

unraid.zip

1 hour ago, IamSpartacus said:

all my shares use cache and none write directly to the array?

Take a look at the shares folder in those diagnostics you posted.

 

You have a number of .cfg files for shares that have no files. These are .cfg files for shares that no longer exist. And you have "duplicate" .cfg files for shares that do have files but have default settings. I say duplicates because the diagnostics use DOS filenaming conventions, which are not case sensitive, so when a file has the same name as another in the same folder, it has (1) appended to it.

 

Probably at some point you managed to create top level folders with a different case than you had specified when setting up user shares. This can happen when you use the wrong case when specifying a path such as the host path in a docker mapping. Those top level folders become user shares also since any top level folder on cache or array are part of a user share named for the folder. And of course, linux is case-sensitive, so if you have top level folders with the same name except for case, they are different user shares.

 

Those share .cfg files in the diagnostics that do not have default settings are actual .cfg files on your flash drive in config/shares, but some of them don't actually correspond to a user share anymore since they have no files. Those share .cfg files in the diagnostics that have default settings don't actually have corresponding .cfg files on your flash, but they do have files and the corresponding user shares have default settings.

 

The default for Use cache is No. So it seems likely that some of your user shares are actually cache-no.

 

36 minutes ago, trurl said:

Take a look at the shares folder in those diagnostics you posted.

 

You have a number of .cfg files for shares that have no files. These are .cfg files for shares that no longer exist. And you have "duplicate" .cfg files for shares that do have files but have default settings. I say duplicates because the diagnostics use DOS filenaming conventions, which are not case sensitive, so when a file has the same name as another in the same folder, it has (1) appended to it.

 

Probably at some point you managed to create top level folders with a different case than you had specified when setting up user shares. This can happen when you use the wrong case when specifying a path such as the host path in a docker mapping. Those top level folders become user shares also since any top level folder on cache or array are part of a user share named for the folder. And of course, linux is case-sensitive, so if you have top level folders with the same name except for case, they are different user shares.

 

Those share .cfg files in the diagnostics that do not have default settings are actual .cfg files on your flash drive in config/shares, but some of them don't actually correspond to a user share anymore since they have no files. Those share .cfg files in the diagnostics that have default settings don't actually have corresponding .cfg files on your flash, but they do have files and the corresponding user shares have default settings.

 

The default for Use cache is No. So it seems likely that some of your user shares are actually cache-no.

 

 

Ok so I see all the extra share cfg files.  Most of those shares don't exist anymore and I've confirmed none of those folders exist on any of my disks.  The only shares I have left are the following:

 

 

Furthermore, while those shares were originally created with capital letters, they've all been converted to lower case.  I guess the 'mv' command while changing the directory case does not change the share.cfg file, I'll have to fix that.  The only shares that are set to Use Cache = Yes (meaning they eventually write to the array) are 4k, media, and data.  And on every disk, those top level folders are indeed lower case.  I've also confirmed all my docker templates reference the lower case shares.  I've also just done a test file transfer to each share and every transfer wound up on cache and not on any of the disks.

 

So if all the top level folders are correct on each of the disks to match the current shares, I'm not sure what could be causing the disk spin ups.

 

 

QUESTION:  If say radarr/sonarr are upgrading a file quality that exists on the array, would that cause a parity write during the write to cache since sonarr/radarr is technically deleting the previous file and overwriting it with the new/better quality version?

Edited May 12, 20206 yr by IamSpartacus

If a user share path corresponds to a file on the array, then replacing that file replaces it on the array.

Any change to the contents of an array drive would cause a spin-up, and this includes changes to directory entries.   A delete operation is a form of write so WOULD definitely cause a spin-up.  

Well than there's my answer.  I suspect Radarr is the cultprit as it's constantly upgrading movie qualities.