Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shodha.enet.dec.com!alan From: alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) Newsgroups: comp.unix.ultrix Subject: Re: Adding/setting up mem, disk, cd drive, sys admin? Summary: Long Reply: Part III. File System Overhead. or, "Why File System Sectors resemble socks". Message-ID: <3388@shodha.enet.dec.com> Date: 16 Jun 91 06:27:44 GMT References: <44675@netnews.upenn.edu> Organization: Digital Equipment Corp. - Colorado Springs, CO. Lines: 112 In article <44675@netnews.upenn.edu>, lau@desci.wharton.upenn.edu (Yan K. Lau) writes: > I added 2 RZ57s in an expansion unit to the system. I ran MAKEDEV and > newfs. The results were about 950megs total with 850megs available. Is > this normal? I read somewhere that the system takes about 10% for > (mumble...mumble). And I responded "This seems to be normal". But where does all the space go you ask? Well, now that we have resolved the disk size (See "Lies, Damned Lies and ..."), we know just how much we have to begin with and can determine how much is lost to file system overhead. That's the key to it you see; file system overhead. Some file system space goes to superblocks, some to inodes and some to other stuff. For some disks this can be a signifi- cant percentage of the disk. We'll find for the RZ57 that it isn't very much. From the previous discussion we determine that whatever else WE might think about it, ULTRIX believes that an RZ57 has 1,954,050 sectors (977,025 KB). Doing a newfs(8) on an RZ57, letting it take the defaults we find that there are a total of 945,726 KB available, a loss of 3.2%. Looking at the RA82 as another example we find it has 608,332 KB which goes down to 584,102 KB for file system data, a loss of 3.98%. Where's the overhead? First, consider the file system structure. Each file system is made up of groups of cylinder. Each of these groups has it's own superblock, block of inodes, data space and cylinder group data. When left to the default each group consists of 16 cylinders. The first cylinder has a few more things thrown in to use up a little space. Here's a summary of the sizes of things on an RZ57: Bootblock: 8 KB (one only)(+) Superblock: 8 KB (one only) Backup Superblock: 8 KB (one per CG) Cylinder Group data: 8 KB (one per CG) Inodes: 256 KB (one per CG) From the previous discussion we might concluded that there were 1,861 cylinders on an RZ57. Looking at the output of newfs(8) it believes the 71 sectors per track which actually gives us 1835 cylinders (one a bit short). Taking the default of 16 cylinders per group this is 115 cylinder groups. The last one will be short, but have the same overhead. Working through the sizes of things we have: Bootblock: 8 KB = 8 KB Superblocks: 8 KB + (8 KB * 115) = 928 KB CG: 8 KB * 115 = 920 KB Inodes: 256 KB * 115 = 29,440 KB -------------------------------------------- 31,296 KB If we take the difference of chpt(8) size and the total file system size we find the result very close; 977,025 - 945,726 = 31,299 That's only three KB unaccounted for. You might think that it's best left a mystery; perhaps they end up in the same place with socks that go missing from dryers, but I think I know where they are. First, look at the original partition size; 977,025 KB. File systems are made up of File System size blocks of data. This is typically 8 KB. If we view the file system space as 8 KB blocks there are 122,128 of them with one little KB left over. That's the first one. Also included in the file system overhead of an RZ57 is something called the cylinder group summary. On the RZ57 with defaults this is 2 KB (trust me, really). So we have: 945,726 + 31,296 + 2 + 1 = 977,025 The mind boggles. Now, having been through the exercise what can we divine (it's getting late folks...)? The amount of space used up in overhead depends on the number of cylinder groups, which in turn depends on the number of cylinders. If a disk consists of very many small cylinders then lots of space gets used. One benefit of this is that you get lots of space for inodes. On some file systems this can be a big win (News disks for example). You can also control the amount of space used for overhead in various ways. There is a flag to newfs(8), passed onto mkfs(8) that controls the size of the inode part. By making this number greater than the default of 2048 you can allocate fewer inodes and therefore less space. With this comes the risk that you don't have enough inodes. If you KNOW that a disk will have only a few large files, then getting back a few dozen MB might be worthwhile. Another way to control the overhead is to lie about the geometry. Using a contrived (^) example of a disk with 69 sectors/track, 13 tracks/cylinder and 3,279 cylinders we might wish to lie and say it has 23 sectors/track, 13 tracks/cylinder and 9,837 cylinders. Or perhaps, 69 s/t, 39 t/c and 1,093 cylinders. Lying about the geometry might have other affects, but that is a topic for a performance project. (+) Actually there is one per file system of the "one only" blocks. (^) Well, maybe not contrived. -- Alan Rollow alan@nabeth.cxn.dec.com