A minimum file system free space of 20% is often advised. When a reason is given it is "performance" or "fragmentation".

Is 20% an optimal figure? Or is it a magic number like having twice the RAM as swap space?

Does a 3 TB file system really need ~600 GB of space without which it will take long to find space for a new file and probably have to fragment it?

What are the actual processes that need to be considered/understood when deciding on an operational free space limit? Or are practical tests required, rather than gedanken experiments?

it's not so much optimal as logical and / or wise. Log files can easily run away with themselves etc, a database file suddenly grows. it just gives you time and flexibility to deal with these things before they exhaust disk space and cause other issues.

"swap = doubel the ram" is very obsolete though.

Actually, the default is 5% on ext type Filesystems
http://linux.die.net/man/8/mkfs.ext4

If you read that page, there are a few other considerations involved as well eg

Thanks acid_kewpie and chrism01

Can I conclude that "Minimum 20% free space on file systems" has about as much rational basis as "Swap = 2 x RAM"?

Certainly we need some free space:

1. To allow for usage growth, perhaps sudden.
2. In the case of ext[234] (all three?), space reserved for root processes (default 5%) and re-sizing.

What about keeping some some free space to avoid excessive fragmentation? That makes sense -- both to ease the work required of the algorithm that identifies free blocks to write to and to reduce the head movements required to write and read a file. But it must depend on the size of the files; if the files were all less than a blocksize there could be no fragmentation; regards this consideration, 20% (less reserved and re-sizing blocks) must be a rough working rule and one that is increasingly wasteful as disk/volume sizes increase.

Swap = 2x RAM really makes no logical sense, I don't know why that was ever a "rule". The swap should simply be enough to handle any RAM overflow given your intended (and "accidental" usage). There's nothing special that happens at swap = 50% or 100% or 200% RAM size that gives that "rule" any credibility.

The 5% reserved space for root is also incredibly antiquated. This default should NEVER have been a fixed percentage, it should have been a fixed size somewhere around 100 MB IMO. It makes no sense to reserve 5% for root on any filesystem. I have a 40 TB RAID on one of my systems, which defaults to 2 TB of reserved space for root. It's completely illogical, root would never need anywhere near that much space on that filesystem if it were to fill up from regular user data.

The 20% free space rule on file systems is very different, however. The main purpose of that rule is to prevent fragmentation, which has very real consequences. I don't know if you've ever used a filesystem up to 95+% usage and kept track of its performance, but once you pass about 85-90% usage the write speed falls off a cliff. Personally, I try to keep my systems below 70%, and if they ever break 90% I make it a priority to re-distribute the data to drop them back down. If I don't, they become almost unusably slow. I'm mostly working with big files though (1-3 GB each), where lack of contiguous space starts to create problems when writing. If you're working with billions of 1 kB files then the rules would change a bit.

When you had a situation where you bought a RAM upgrade or fed your children, there was a good logic in the trade off between financial cost and access speed. Irrelevant now of course.

Thanks suicidaleggroll

Good to have an observation on the rationality of 5%.
Thanks for the real-world data.

I've installed Phoronix Test Suite in preparation for doing some tests. Haven't figured out how to make it test a specific file system yet ...

The Phoronix test suite didn't do what I wanted so I wrote a script and ran initial tests on a 15 GB ext4 file system on a SATA 6 HDD and port.

The results do not tell a clear story. Of the ten plots:

• Three show the conventional result of task times getting longer as file system usage increases but the effect starts around 50 to 60%, not the conventional 75 to 80%. All three tests concern 10,000 directories (creating them, finding them and finding and removing them).
• Five show task times staying broadly similar throughout the test, with file system usage changing from 30 to 98%. All five show the test task taking longer during roughly 60 to 80% usage and returning to pre-60% times until the end of the test at 98% usage. These five tests concern either 10,000 directories (creating them, finding them and finding and removing them) or a 0.5 GiB file (reading or creating it).
• The remaining two plots show test times more or less consistent from 30 to 80% file system usage and then reducing by more than 50% from 80 to 98% usage.

A fuller report, including the script's git link and attached tarchive (of test log, report and gnuplots) is in Blue Light's WIKI at (shortlink) http://wiki.bluelightav.org/x/uANIAQ

Interesting. Your first and third bullet tend to match up with what I've seen in practice, not sure what's going on on the second bullet.