Hi All,

 

I believe I have discovered what the cryptic rule is as of unRAID 5.0rc5 (identical to 5.0beta14 I believe) regarding when a write will fail with 'No Space Avaible'. This is what I (as a result) have written on the wiki:

 

http://lime-technology.com/wiki/index.php?title=Plugin/webGui/Share_Settings

 

The min free space defines the minimum free space there must be a disk assigned to the share before writing will be allowed to the share. If a cache disk is not present, the share can only be written if the defined min.free space is available on a disk.

 

If split level is defined, then beware that writing will be permitted to a disk with less than Min Free space available, if writing to a directory beyond the split limit. So if a folder has already been assigned to a specific disk due to a split level, then the min-free-space check is omitted. Hence with a Split level of 1, and no disks with min free space available and an overfilled cache disk (or no cache disk), ONLY writing to the root folder will cause a write error.

 

If a cache disk is present, and the cache disk is not overfilled, then the share will allow writing even though the share is overfilled thus ignoring the Min. Free space parameter defined here. However if the disks are filed beyond the Min. Free space limit then the mover process will fail to move files and the a syslog entry will be created saying roughly 'shfs/user: shfs_mkdir: assign_disk: media/4 (28) No space left on device'. (This min-free-space behaviour is present in unRaid v5b14 + v5.0rc5, maybe other versions behave differently).

 

So my question: Is this really the intended behaviour? It seems not, as neither the cache nor the split level interaction with min-free-space is described here: http://lime-technology.com/wiki/index.php/Un-Official_UnRAID_Manual#Min._Free_Space

 

Cheers Alex

The min free space defines the minimum free space there must be a disk assigned to the share before writing will be allowed to the share. If a cache disk is not present, the share can only be written if the defined min.free space is available on a disk.

Not exactly. It is the required free space on a particular disk required by the share for it to be selected for writing.

If split level is defined, then beware that writing will be permitted to a disk with less than Min Free space available, if writing to a directory beyond the split limit. So if a folder has already been assigned to a specific disk due to a split level, then the min-free-space check is omitted. Hence with a Split level of 1, and no disks with min free space available and an overfilled cache disk (or no cache disk), ONLY writing to the root folder will cause a write error.

This sounds like a bug.

If a cache disk is present, and the cache disk is not overfilled, then the share will allow writing even though the share is overfilled thus ignoring the Min. Free space parameter defined here. However if the disks are filed beyond the Min. Free space limit then the mover process will fail to move files and the a syslog entry will be created saying roughly 'shfs/user: shfs_mkdir: assign_disk: media/4 (28) No space left on device'. (This min-free-space behaviour is present in unRaid v5b14 + v5.0rc5, maybe other versions behave differently).

Min free space is applied to individual disks. Since the cache has space it will be used. If none of the disks in the share have space the move will fail.

Yes, that's the way it is. The split level over-rules all else and data placed on the cache doesn't care about the share min-free setting. Technically I suppose the description I wrote is wrong. It basically just doesn't allow a new folder within the split level settings to be created.