gregnostic

Clearly my mental model on this based on how it's described in the Unraid UI was way off. I understand now why Unraid behaves the way it does and why the share value of "Minimum Free Space" overrides the global cache value. That's not to say I agree with or like this behavior, but at least I understand it now. Thanks.

Huge +1 on this. The cache already has its own global "Minimum Free Space" option under the "Cache Settings" header. Unraid should not ignore this in favor of a share's free space settings, which should be a value optimized for the array disks. Overriding the global cache value with something share-specific leads to negative, unexpected behavior. Separate to that issue, I'm also going to echo what ados said above: when you have an array with multiple disk sizes, a static number of bytes to keep free doesn't make sense. Keeping enough free space for a large drive means a small percentage of usable space on a small drive. Instead, I propose we be allowed to set a percentage in the "Minimum Free Space" fields. Setting a value of, say, 10% would allow you to reserve 1 TB free on a 10 TB drive but only reserve 500 GB on a 5 TB drive. By having to set a fixed value in bytes, you're either losing drive usage on lower drives OR you're risking filling up a disk too much and slowing it down due to fragmentation. Neither of these is a good option. (I also realize that the intent behind the field's help text of "Choose a value which is equal or greater than the biggest single file size you intend to copy to the share." is intended to prevent fragmentation, but in the case of a share where files may be deleted and written a lot, this fragmentation can happen even if all the files are under that threshold.)