[TUHS] tunefs -m 5%
Greg 'groggy' Lehey
grog at lemis.com
Sat Mar 6 11:16:48 AEST 2021
I haven't redirected this reply to COFF, though I was considering
doing so: it
On Friday, 5 March 2021 at 1:50:32 -0800, John Gilmore wrote:
> John P. Linderman <jpl.jpl at gmail.com> wrote:
>> I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB.
> At one point in hystery, ext2 performance was reported to suffer badly
> if there was less than 5% of disk space available in an active
> filesystem. My naive belief, probably informed by older and wiser heads
> around Sun, was that when the file system was >95% full, ext2 spent a
> lot of time seeking around in free lists finding single allocatable
> blocks. And there were no built-in "defragmentation" programs that
> could easily fix that.
This appears to have been inherited from UFS. My recollection is
pretty much the same for UFS, and even the man page entry for EXT4 is
closely related to UFS newfs(8):
Specify the percentage of the filesystem blocks reserved for
super-user. This avoids fragmentation, and allows
daemons, such as syslogd(8), to continue to function
after non-privileged processes are prevented from writing to
filesystem. The default percentage is 5%.
The percentage of space reserved from normal users; the minimum
free space threshold. The default value used is defined by
MINFREE from <ufs/ffs/fs.h>, currently 8%. See tunefs(8) for
more details on how to set this option.
And I can confirm that file systems slow down significantly after the
last 1% of free space has been used.
> Is that still a performance constraint in ext4, which has had a few
> decades to work out those edge performance issues?
Hopefully Ted will comment. But UFS has had even more decades. And
arguably 600 GB on a modern disk is less of a concern than 15 MB on a
300 MB disk 40 years ago.
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 163 bytes
Desc: not available
More information about the TUHS