dff@morgan.com (Daniel F. Fisher) (01/05/89)
In v7n62 frank@morgan.com (Frank Wortner) writes: > "Thrashing" can occur if the filesystem gets too full. . . BSD "fast" > filesystem implementations usually reserve the last 10% of available > space just to insure that this does not happen. In v7n67 mcvax!ritd.co.uk!mr@uunet.uu.net (Martin Reed) writes: > I am pondering whether the "minfree" default of 10% makes sense with the > very large file systems that we are beginning to see (1Gb+). This raises a very interesting question: Does the 10% rule of thumb, which is quite ancient (maybe even 6 years old :-), hold for a 1GB+ file system? Though it is plausible, it is not obvious that the point of thrashing should scale directly with the size of the disk. Has anyone out there bench marked this? Daniel F. Fisher dff@morgan.com
mangler@csvax.caltech.edu (Don Speck) (01/14/89)
The "minfree" parameter is necessary to provide a free space pool for fragment coalescing. Never set the minfree so low that you run out of free whole blocks before "df" says it's full. You'll think you have space, but won't. The smaller the ratio of average (median?) filesize to blocksize, the larger the minfree needs to be. If you must use an 8K/1K filesystem for netnews (average filesize of 2.5K), minfree should be large, 15-20%. Filesystems containing mostly large files can use a small minfree, since large files allocate only whole blocks. Files created when the disk isn't very full, which are not changed when the disk is near full, do not contribute to rising fragmentation. Fsck reports the amount of free space that occurs as fragments. The above considerations dictate that minfree has to be at least 3-5% for typical user filesystems. To maintain speed of sequential transfers, you want enough additional space that a free block can usually be located on the same cylinder, in a rotationally optimal position. (The latter can only matter if you set rotdelay correctly). Rotational optimization is a moot point on typical servers, which are seeking between partitions all the time anyway, except during backups and I/O benchmarks. Inodes are another place one can often economize on space.