In message <https://marc.info/?l=openbsd-misc&m=177714116632263&w=1>, Public Netizen asked > In the man page for tunefs(8) under option "-m minfree" I read: > > "This value can be set to zero, however up to a factor of three in > throughput will be lost over the performance obtained at a 5% > threshold." > > Is this for both reads and writes? Is it even still the case? And does > someone understand why and what's going on?
Take a look at the original 1984 McKusick et al paper "A Fast File System for Unix" at (e.g.) <https://people.eecs.berkeley.edu/~brewer/cs262/FFS.pdf>. The last paragraph of section 3.1 reads: > In order for the layout policies to be effective, a file system cannot be > kept completely full. For each file system there is a parameter, termed the > free space reserve, that gives the minimum acceptable percent- age of file > system blocks that should be free. If the number of free blocks drops below > this level only the system administrator can continue to allocate blocks. > The value of this parameter may be changed at any time, even when the file > system is mounted and active. The transfer rates that appear in section 4 > were measured on file systems kept less than 90% full (a reserve of 10%). > If the number of free blocks falls to zero, the file system throughput > tends to be cut in half, because of the inability of the file system to > localize blocks in a file. If a file system's performance degrades because > of overfilling, it may be restored by removing files until the amount of > free space once again reaches the minimum acceptable level. Access rates > for files created during periods of little free space may be restored by > moving their data once enough space is available. [[...]] This makes it clear that the issue is how the filesystem allocates blocks when writing a new file -- making /minfree/ too small makes it less likely that newly-allocated files will be contiguous on disk. Even if today's solid-state disks don't have "seek time", non-contiguous files still incurr increased overhead at ever layer of the I/O stack. -- -- "Jonathan Thornburg [remove -color to reply]" <[email protected]> (he/him; currently on the west coast of Canada) [in response to Microsoft adding "AI" features to Windows 11] "If they want to make their AI truly useful, train it to move a figure in Word and not trash the document's formatting." -- /ArsTechnica/ commenter "TappedOut", 2025-10-17 "What would you train it on? There are no existing examples of anyone successfully doing that." -- reply from /ArsTechnica/ commenter "GFKBill", also 2025-10-17
