Return to BSD News archive
Xref: sserve comp.unix.internals:8205 comp.unix.bsd:15988 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.hawaii.edu!ames!pacbell.com!well!nntp-ucb.barrnet.net!agate!howland.reston.ans.net!gatech!bloom-beacon.mit.edu!crl.dec.com!crl.dec.com!nntpd.lkg.dec.com!nntpd2.cxo.dec.com!nabeth.cxo.dec.com!alan From: alan@nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for Wayward Inodes.) Newsgroups: comp.unix.internals,comp.unix.bsd Subject: Re: Fast File System: optimizing arguments to newfs Date: 17 Jan 1995 23:24:25 GMT Organization: Digital Equipment Corporation Lines: 81 Distribution: world Message-ID: <3fhjj9$jb1@nntpd2.cxo.dec.com> References: <MARC.95Jan13161859@dun-dun-noodles.cam.ov.com> Reply-To: alan@nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for Wayward Inodes.) NNTP-Posting-Host: nabeth.cxo.dec.com In article <MARC.95Jan13161859@dun-dun-noodles.cam.ov.com>, marc@cam.ov.com (Marc Horowitz) writes: > > 1) News spool. Lots and lots of small files. > 2) Random storage. User homedirs, some packages, etc. Widely >varying file sizes. > 3) JPEG archive (since I don't know if I want to use GIF's anymore >:-). Generally very big files. Other posters have commented on what to use for number of inodes, block and fragment size. The only suggestion I can add is, where feasible, benchmark. This may be especially useful when chosing the fragment size for a file system destined to hold large files. If an implementation is notably faster having the block and fragment size be the same, a benchmark should show it. Such a choice probably only matters when the files are being written. If the disk is really going to be an archive, and not written much, then write time isn't as important as read time. Chosing a value for minfree is a different matter. The 10% value for minfree was found to be a good one when disks were in the 67 to 512 MB range, with the typical probably around 250 MB. With 2 GB disks common and 9 GB disks available, giving up between 200 and 900 MB is probably overkill. So what's a better value? The goal of having some free space is to allow the allocation algorithms to be able to quickly find some free space for a file. Further the search is done by cylinder group, so the goal is to have reasonable free space per cylinder group. So, rather than a general percentage, it might be best to see how a given percent allows for each cylinder group. Example; if minfree is 2% on a 2 GB disk (~40 MB) and there are 300 cylinder groups, each should average 136 KB free, when the disk is full (for user allocations). If the disk has 40 cylinder groups though, it will average 1 MB per group. Both may be perfectly reasonable value depending on the files being allocated. Taking the RM05, one of the MASSBUS disks for which the 10% value was chosen we might get a clue. It had 250,192 KB, spread among 832 cylinders (32 x 19). 10% of this was about 25,000 KB. At a default of 16 cylinders per group there would have been 52 cylinder groups. Thus, the 10% minfree would have represented about 480 KB per group. Now, I'll apply the 480 KB per group average to a 2 GB disk, the RZ28. It has 2,055,240 KB in 2595 cylinders (99 x 16, reported geometry). Using the newfs defaults it will have 163 cylinder groups. At 480 KB per group this will be 78,240 KB or 3.81% of the capacity, well below the "standard" 10% value for minfree. The harder question is whether the magic number of 480 KB per group derived from the RM05 is sufficient today for a similar work-load. If it is a good guideline (around half a MB), then it offers a good clue what the "right" value for minfree will be given the number of cylinder groups and capacity. Some adjustments will need to be made for work-load. A write intensive work-load on a file system designed for large files will probably want more free space per group than typical, if only to keep long contiguous strings together (maxcontig). For ULTRIX and OSF (can't speak for other implementations), the most contiguous space that will be allocated within a cylinder no matter the size of value of maxbpg is 16 MB, the amount address by an indirect block. For your implementation, you may want to see if this is true and take it into account when designing a FFS for large files. > >*How* do I want to choose parameters for newfs for these disks? >Examples welcome. > > Marc > -- Alan Rollow alan@nabeth.cxo.dec.com