Can "minfree" be set to 0% for UFS?

[aragats]

According to newfs() and tunefs() the option -m (the percentage of space held back from normal users): "Settings of 5% and less force space optimization to always be used which will greatly increase the overhead for file writes".

Can it be set to 0% without losing performance — since there is nothing to optimize? E.g. if I have a partition used as a storage for not-so-important stuff, and I don't care if it doesn't have reserved space.

 

[mer]

I'm not sure if there is a relation between this value and what root user can do, but the part you quoted says "...greatly increase the overhead for file writes". Couple that with you saying "...a partition used as storage..." the implication is it may take longer to do the writes to storage which is a potential performance hit..

I think on UFS that specific value only comes into play as a file system fills up, so if the filesystem is say less than 70% utilization there may be no measurable difference. As the filesystem fills up, things may/will change.

 

[bob2112]

I'm not sure if there is a relation between this value and what root user can do,

It's simply that the limit doesn't apply to root writes.

 

[Phishfry]

I don't see it improving performance at all.
It is a safety. If you try and write to a disk at 93% the filesystem sends out a notice. Disk is full.
If you set it at 0% and try and write a file to a near full disk it will crash the machine. No warning.

 

[aragats]

try and write a file to a near full disk it will crash the machine.

Why would it crash? I'm not going to do that to the main system partition. As I mentioned, It's another partition just for storage of not-so-important stuff.

 

[Phishfry]

Where do crash dumps go when disk is full.

Real machines are running other things. When they all run out of disk space what happens?

That is assuming a single disk/OS partition like I use.

 

[Phishfry]

There is no way I would use zero personally. Ever. One percent minimum to give yourself a buffer.
Benchmark it an see if it makes a difference. There would have to be some gain to bother.

 

[aragats]

Real machines are running other things. When they all run out of disk space what happens?

|_____system /dev/da0p1_____|_____storage /dev/da0p2_______|

Nothing will happen to the system and its rootfs (da0p1) if the "storage" partition is full. Some data on "storage" (da0p2) may be lost or some files may get corrupted.

One percent minimum to give yourself a buffer.

That's the question. The man page doesn't recommend going below 5% because of degraded performance. I would assume that 0% would not degrade performance.

You're right though, I should just benchmark. I thought, somebody already knows the answer.

 

[ShelLuser]

Can it be set to 0% without losing performance — since there is nothing to optimize? E.g. if I have a partition used as a storage for not-so-important stuff, and I don't care if it doesn't have reserved space.

That is actually explained in tunefs(8), and the answer is no. Because this isn't just about userland, but it will also affect the way in which the system utilizes the filesystem. See also -o in newfs(8).

I quote:

Settings of 5% and less force space optimization to always be used which will greatly increase the overhead for file writes.

And that's only one part of it. As mentioned in that same manual page this setting can also affect fragmentation, or the avoidance of it. With system settings like these the motto is simple: don't try to outsmart the system unless you know what you're doing. Ergo: if you're unsure about things then don't change default settings.

When in doubt... why not check the mentioned include file (ufs/ffs/fs.h)? You'll normally find it in /usr/include:

/*
* MINFREE gives the minimum acceptable percentage of filesystem
* blocks which may be free. If the freelist drops below this level
* only the superuser may continue to allocate blocks. This may
* be set to 0 if no reserve of free blocks is deemed necessary,
* however throughput drops by fifty percent if the filesystem
* is run at between 95% and 100% full; thus the minimum default
* value of fs_minfree is 5%. However, to get good clustering
* performance, 10% is a better choice. hence we use 10% as our
* default value. With 10% free space, fragmentation is not a
* problem, so we choose to optimize for time.
*/

So, yes, it can be set to 0 but the moment you reach the threshold you may run into performance issues. And heres' the problem with that: will you still remember that you changed this setting should such problems arise in, say, 1 or 2 years?

Honestly? I'd say it's not worth the hassle, at all. I mean, it's not as if you're giving up free space

 

[Charlie_]

If you repeatedly perform write and delete operations while the optimization preference
is set to space, fragmentation will increase.
With an HDD, the drop in performance is noticeable.

 

[Charlie_]

If you want to increase available space - even just a little - reducing the number
of inodes is recommended.
It also speeds up fsck.

 

[drsnx60]

If you set minfree to 5% or lower you will force Space optimization. The filesystem will squeeze data in every little hole that previously was left empty like the last 1K bytes of an 8K block that TIme Optimization left empty. This will lead to increased amounts of accesses and mounting time spent on SEEKs on a HDD.
If you have TeraBytes sized Filesystems you can probably Lower minfree to 6% with little risk ( eg 60 GB )
Depends on the size of your files.

 

[ralphbsz]

I don't see it improving performance at all.

On the contrary, having a file system that is very full reduces performance. Even on SSDs. Using min free to remind the administrator that they should do something (delete some files, get more space, rearrange thing, compress, ...) is a good thing.

If you set it at 0% and try and write a file to a near full disk it will crash the machine. No warning.

That's not wrong, but also not completely correct.

If a normal user process fails to write, because the disk is full, that will either be handled by the process (if the code is written with good error handling), or it will cause the user process to fail. This will not cause the OS to crash. The user might get frustrated, in particular if the process is something they really care about (like their window manager).

If a process owned by root fails to write, the same thing happens. EXCEPT that there are some processes that are so important to system operation that their failure will either cause the OS to crash outright (although I can't think of good examples right now), or de-facto require a reboot to get things back up. So full disk causing system crash is real, but a side effect.

 

[T-Aoki]

Even putting performance penalties aside, setting minfree to 0 (or too low) could cause unfixable filesystem.

Once the filesystem becomes full by non-root user writes and the write is NOT finished (it may be quire rare that the last file to be written occupies exactly same free sectors/clustors), it causes crash of the process that writes it as already explained by others.

But what if the quite rare state happenes, and any of the users noticed something needed to be deleted?

The deletions are NOT always simple "overwrites" of existing metadata, even if softupdates nor journaling (regardless via UFS or via GEOM) are activated.
And if any additional sector(s) is/are required, there's nothing to do, except adding new drive / partition that can create larger filesystem and copy everything to it, then alter to it.

If there are some spare space that root alone can write into, users can request root to delete some specified files and root can forcibly delete them.

And more likely-to-happen situation is, if some crash (related or unrelated with the "disk full") happenes and the filesystem is left "dirty" flag on, fsck (as root) should be invoked on following reboots. But if there's no sufficient free space, fsck cannot write anything that are needed to fix the filesystem (you'll remember, this usually happen with unfinished writes!), thus, unfixable.

Performance reduction is important, but this is fatal.