Minimum Free Space Question

[SigmaInigma]

I'm creating a new share for my Plex Media server. I've read that you should set the minimum file size to twice the amount of the largest file that you plan to store on the drive. Right now that is only 10GB but in the future I may add 4K movies so I decided to set the minimum file size to 60GB. When I first set up my server several folders like appdata were automatically created for docker containers. These shares are set to 0 for the minimum free space. Is this a problem? I'm not sure I fully understand it.

[garycase]

Basically the issue is simple:  UnRAID will NOT span a file across multiple disks; 'nor does it "know" the size of a file you're writing to it until after the write starts.  So if your current allocation method and/or split level results in a specific disk being used for a new file, if there's not enough room for that file the copy will fail.  The minimum free space simply says "don't start a copy unless the target disk has at least this much space".    This doesn't need to be "twice the size" of the largest file you're going to ever write -- that's just protection against expanding requirements [what you THINK is the largest file you'll ever write may prove to be too small in the future  ].

 

The appdata shares with 0 min free basically say "as long as there's space available, use the drive" => they would fail if there wasn't space; but hopefully you're using a large enough drive that you're not going to have a space issue.  Typically these would be on your cache drive, which is hopefully a good bit larger than you'll need for these shares.

 

[trurl]

And any top level folder on cache or any array disk is automatically a user share. A user share has default settings unless you change them. Minimum free = 0 is just the default.

[SigmaInigma]

Basically the issue is simple:  UnRAID will NOT span a file across multiple disks; 'nor does it "know" the size of a file you're writing to it until after the write starts.  So if your current allocation method and/or split level results in a specific disk being used for a new file, if there's not enough room for that file the copy will fail.  The minimum free space simply says "don't start a copy unless the target disk has at least this much space".    This doesn't need to be "twice the size" of the largest file you're going to ever write -- that's just protection against expanding requirements [what you THINK is the largest file you'll ever write may prove to be too small in the future  ].

 

The appdata shares with 0 min free basically say "as long as there's space available, use the drive" => they would fail if there wasn't space; but hopefully you're using a large enough drive that you're not going to have a space issue.  Typically these would be on your cache drive, which is hopefully a good bit larger than you'll need for these shares.

 

I see, I thought a cache drive is not permanent storage though? I have a small SSD that I could use as a cache drive. Would it benefit me to move the appdata folder to the cache drive? How would I go abiut doing that? I have a PlexMediaServer installed in my app data folder.

[trurl]

I see, I thought a cache drive is not permanent storage though? I have a small SSD that I could use as a cache drive. Would it benefit me to move the appdata folder to the cache drive? How would I go abiut doing that? I have a PlexMediaServer installed in my app data folder.

Set appdata user share to Use cache disk: Prefer and run mover.

[SigmaInigma]

I see, I thought a cache drive is not permanent storage though? I have a small SSD that I could use as a cache drive. Would it benefit me to move the appdata folder to the cache drive? How would I go abiut doing that? I have a PlexMediaServer installed in my app data folder.

Set appdata user share to Use cache disk: Prefer and run mover.

 

Why prefer and not only? I would like to move my appdata folder to the cache drive permanently. The Plex Media server is always running. There is no need for the my drives to be spinning unless I am watching a movie. What would be the best way to do this?

[JorgeB]

Like trurl posted changing the share to prefer and running the mover will do what you want.

[itimpi]

I see, I thought a cache drive is not permanent storage though? I have a small SSD that I could use as a cache drive. Would it benefit me to move the appdata folder to the cache drive? How would I go abiut doing that? I have a PlexMediaServer installed in my app data folder.

Set appdata user share to Use cache disk: Prefer and run mover.

 

Why prefer and not only? I would like to move my appdata folder to the cache drive permanently. The Plex Media server is always running. There is no need for the my drives to be spinning unless I am watching a movie. What would be the best way to do this?

prefer will act the same as Only once all the files for the share are on the cache disk.  The reason that Prefer is suggested is that this provides an automated way to get files for such a share that are currently on an array disk moved to the cache disk.  This is particularly convenient for those who add a cache disk later, or change their mind about whether an existing share should be on the cache disk.

[SigmaInigma]

prefer will act the same as Only once all the files for the share are on the cache disk.  The reason that Prefer is suggested is that this provides an automated way to get files for such a share that are currently on an array disk moved to the cache disk.  This is particularly convenient for those who add a cache disk later, or change their mind about whether an existing share should be on the cache disk.

 

I've set the appdata folder to prefer on the cache and ran the mover script. It copied all the app data folder to my cache drive like you said, but the appdata still remains on the array as well. Is this normal behaviour? In the future will it read and write from the cache and not the array?

[Squid]

prefer will act the same as Only once all the files for the share are on the cache disk.  The reason that Prefer is suggested is that this provides an automated way to get files for such a share that are currently on an array disk moved to the cache disk.  This is particularly convenient for those who add a cache disk later, or change their mind about whether an existing share should be on the cache disk.

 

I've set the appdata folder to prefer on the cache and ran the mover script. It copied all the app data folder to my cache drive like you said, but the appdata still remains on the array as well. Is this normal behaviour? In the future will it read and write from the cache and not the array?

If files / folders are open, then those files / folders will not get moved.  But, an empty appdata share sitting on the array will cause no ill effects, and you won't even notice it since most access to the shares is via /mnt/user/....

[trurl]

prefer will act the same as Only once all the files for the share are on the cache disk.  The reason that Prefer is suggested is that this provides an automated way to get files for such a share that are currently on an array disk moved to the cache disk.  This is particularly convenient for those who add a cache disk later, or change their mind about whether an existing share should be on the cache disk.

 

I've set the appdata folder to prefer on the cache and ran the mover script. It copied all the app data folder to my cache drive like you said, but the appdata still remains on the array as well. Is this normal behaviour? In the future will it read and write from the cache and not the array?

What are you looking at that is telling you it is still on the array?

[gnollo]

I remember reading somewhere that if you fill more than 95% of the drive, it will result in performance issues in unraid. Is that accurate still? (or was it ever?)

[JorgeB]

29 minutes ago, gnollo said:

I remember reading somewhere that if you fill more than 95% of the drive, it will result in performance issues in unraid. Is that accurate still? (or was it ever?)

Yes for reiserfs disks, though performance can degrade even before that, not important for xfs or btrfs, but you'll want to leave always a few GB free.

[pwm]

25 minutes ago, gnollo said:

I remember reading somewhere that if you fill more than 95% of the drive, it will result in performance issues in unraid. Is that accurate still? (or was it ever?)

Different file systems behaves differently when nearly full.

 

But in general, you should never fill a file system almost full unless it's an archival disk where you only write to it once and then leave it in that state with no more writes. An almost full disk has a very hard problem figuring out what free space to use for new writes with tends to result in very severe fragmentation. So you can get huge slowdowns accessing some of the files if you make use of all space for a partition.

 

Note that some file systems can allocate a bit of extra space, speculatively, for some files just to allow them to be extended without additional fragments. If you then fill the disk full, then the file system may have to go back and try to get back these speculative allocations and take a huge number of small blocks to store the last files written.

[gnollo]

I'm on reiserfs, never switched the disks across, long time user of unraid. I manually write files to the latest added disk to the array, filled disks (to 95%) never get touched again, as I only use the drives as repositories for video and music files, I use the cloud for documents backups.

Should I have 90% free on the disks instead? what is the limit where reiserfs performance starts degrading?

[JorgeB]

6 minutes ago, gnollo said:

what is the limit where reiserfs performance starts degrading?

There's no specific limit, depends mostly on the disk size and number of files, the more small files the worse.

[pwm]

1 hour ago, gnollo said:

I remember reading somewhere that if you fill more than 95% of the drive, it will result in performance issues in unraid. Is that accurate still? (or was it ever?)

I have managed quite well to store DVD/BD ISO files to Reiserfs and fill to 99% on older 4 TB volumes.

But the special case is that I have only accumulated new files - never erased any existing files. And the total number of files are very low since the ISO images are on average 8 GB for the DVD rips and 44 GB for the BD rips. I also have a few, very small, meta-data files for each rip, but still ends up with a multi-GB average file size.

 

In the general case, 99% is much too high filling level for ReiserFS. RFS starts to spend significant time rebalancing the internal tree structures much earlier, so 90% should be a better general figure - especially if there are important real-time requirements.

 

But just to reiterate: all file systems gets affected when nearly full. It's just a question of how early you start to see significant effects for a specific set of files. Some file systems suffers because the free-space management breaks down. Some, because the FS tries to balance the internal structures. If it's balancing operations that slows down, then it can work quite well to fill the FS to a high level since the rest of the file system life will be reads. But if it's the free-space management that breaks down, then even future reads are likely to become severely affected.

[gnollo]

I have managed quite well to store DVD/BD ISO files to Reiserfs and fill to 99% on older 4 TB volumes.

But the special case is that I have only accumulated new files - never erased any existing files. And the total number of files are very low since the ISO images are on average 8 GB for the DVD rips and 44 GB for the BD rips. I also have a few, very small, meta-data files for each rip, but still ends up with a multi-GB average file size.
 
In the general case, 99% is much too high filling level for ReiserFS. RFS starts to spend significant time rebalancing the internal tree structures much earlier, so 90% should be a better general figure - especially if there are important real-time requirements.
 
But just to reiterate: all file systems gets affected when nearly full. It's just a question of how early you start to see significant effects for a specific set of files. Some file systems suffers because the free-space management breaks down. Some, because the FS tries to balance the internal structures. If it's balancing operations that slows down, then it can work quite well to fill the FS to a high level since the rest of the file system life will be reads. But if it's the free-space management that breaks down, then even future reads are likely to become severely affected.

Thanks, I'm not experiencing issues once disks are all spun up, so I'll keep 95% as my rule of thumb. I also rip bluray movies full quality and create smaller bdrips for movies I don't care so much to save some space.

Sent from my Nexus 5 using Tapatalk

[airport]

Dear all, in my case, what should I do when the hard drives are almost 100% full capacity, I just added 1 hdd 10TB to the array to expand the unRAID capacity, but I want all the existing hdds to automatically dynamically move the data in there so that all these hdds have about 50GB free. Thanks.

[trurl]

4 hours ago, airport said:

automatically dynamically move the data

That doesn't happen. You might try unBALANCE plugin. Or Dynamix File Manager plugin to help you move things yourself.

 

If you want further advice, attach diagnostics to your NEXT post in this thread.

[airport]

Thanks for your response.

Here is my attached file.

 

1mehien-diagnostics-20230112-1013.zip

[trurl]

I guess we won't worry too much about your appdata, domains, system shares since you don't have cache anyway, but I have to wonder how you wound up with system share having files on 4 different disks. It normally only has 2 files in it.

 

You have so many user shares I didn't check them all, but saw many with no Minimum Free set. There are many more recent threads that discuss this in more detail, but basically you should have Minimum Free for each user share set to larger than the largest file you expect to write to the share.

 

Also, you should always try to keep some free space on all disks since filesystem repair needs some space to work in if that is ever needed. And, it is especially important to avoid overfilling btrfs as most of your disks are, since it seems to corrupt easier than xfs, and is also harder to repair.

 

Several of your disks are too full.

 

I also saw some user shares set to Allocation method Fillup. I usually avoid this setting, but it can be OK if you never intend to write to a disk again after it reaches Minimum Free. I always recommend against Allocation method Most Free, it isn't really any better than Highwater in the long run and is the least efficient method.

 

And I saw some user shares with Included and/or Excluded disks. There is never any good reason to set both and you shouldn't do it. Include means Only the listed disks. Exclude means Except for the listed disks.

 

For example, you have a user share anonymized as 'h------i' with

shareInclude="disk14"
shareExclude="disk1,disk2,disk3"

So, you are telling it to use Only disk14, and at the same time, you are telling it to use all disks Except disk1,disk2,disk3. Obviously, this makes no sense.

 

Use either Include or Exclude, never both. And also consider that if you add a disk and a user share has Include set, it won't use the new disk unless you Include it.

 

14 hours ago, trurl said:

You might try unBALANCE plugin. Or Dynamix File Manager plugin to help you move things yourself.

 

unBALANCE might be a little more trouble to figure out. I haven't really used it. But it will let you automate the moves. Dynamix File Manager is good to have around anyway.

 

If you try to use some other method to move files, be sure you don't attempt to work with disks and user shares together. It is easy to get in trouble that way. And, in fact, working with user shares won't really help get things moved from disks anyway, so only work with the disks while trying to get things cleaned up.

 

[airport]

Thank you very much for your informations.

I'll try Dynamix File Manager for my unRAID.

[airport]

4 hours ago, trurl said:

I guess we won't worry too much about your appdata, domains, system shares since you don't have cache anyway, but I have to wonder how you wound up with system share having files on 4 different disks. It normally only has 2 files in it.

 

I also saw some user shares set to Allocation method Fillup. I usually avoid this setting, but it can be OK if you never intend to write to a disk again after it reaches Minimum Free. I always recommend against Allocation method Most Free, it isn't really any better than Highwater in the long run and is the least efficient method.

 

And I saw some user shares with Included and/or Excluded disks. There is never any good reason to set both and you shouldn't do it. Include means Only the listed disks. Exclude means Except for the listed disks.

 

For example, you have a user share anonymized as 'h------i' with

shareInclude="disk14"
shareExclude="disk1,disk2,disk3"

So, you are telling it to use Only disk14, and at the same time, you are telling it to use all disks Except disk1,disk2,disk3. Obviously, this makes no sense.

 

Use either Include or Exclude, never both. And also consider that if you add a disk and a user share has Include set, it won't use the new disk unless you Include it.

 

 

 

 

Thanks for your suggestions, I have adjusted the parameters for sharing folders to be more secure for the system.