harthc@ntmtv.UUCP (Howard Hart) (02/21/91)
As the title says, how do I go about doing this on a Sun 3/280 running
SunOS 4.0.3. I've been told by a knowledgeable source that newfs is
broken and you have to use mkfs to do this. Any guesses (educated, of
course). Thanks in advance.....
--
Howard Hart UUCP:{ames,pyramid!amdahl,hplabs}!ntmtv!harthc
System Administrator INTERNET: ntmtv!harthc@ames.arc.nasa.gov
Northern Telecom PHONE: (415) 940-2680
Mt. View, CAverber@pacific.mps.ohio-state.edu (Mark Verber) (02/22/91)
Sigh... yes, newfs on SunOS 4.0.3 is busted. Under anything later than SunOS 4.0.3 (eg 4.1, 4.1.1) newfs does work, and all you have to do is specify your preferred bytes/inodes with the -i flag. If you are going to continue running 4.0.3 for awhile you have do something a bit more ugly. Here are the basic instructions. The problem is that you can't tell mkfs directly how many inodes to create. It figures the number for itself. There are about 5 numbers that interact. Unfortunately, several of them have maximum or minimum values, so you don't even get to specify them. Altogether, it looks like mkfs was designed to make it as hard as possible to increase the number of inodes. In theory, you should be able to specify more than the usual number of inodes per cylinder group. However in practice it generally seems to be sitting at 2048, which is the maximum value. So attempts to increase it are ignored. Since you can't increase the umber of inodes / cylinder group, you have to increase the number of cylinder groups. This is computed from the cylinders per cylinder group. So you have to decrease the number of cylinders per cylinder group. This is an argument to mkfs, so in some cases you can just specify it as 4 or 8. I've actually gotten this to work sometimes. Unfortunately, sometimes mkfs won't let you specify anything less than 16. Now things get hairy. The way mkfs computes the minimum number of cylinders per group is sort of odd. It gets initialized to 16 (at least for the disks I've seen). Then a loop is done which divides both cylinders per group and sectors per cylinder by 2, until sectors per cylinder is odd. If the number of sectors per cylinder starts out odd, of course this loop stops immediately, and you get 16 cylinders per group. I managed to fix things up by telling mkfs not to use all the sectors on a track. In case this isn't obvious, what I'm doing is telling mkfs to ignore some of my disk space. The number that needs to be even is sectors per cylinder, which is of course sectors per track times tracks per cylinder. In your case /dev/rxd0e: 175874 sectors in 175 cylinders of 15 tracks, 67 sectors 15 * 67 is 1005 sectors per cylinder. This is odd, so you're stuck. If you specify 66 instead of 67, you get 990, which is even. So you get to specify 8 cylinders per group, and double your inodes. If you need more, specify 64. 15 * 64 is divisible by 4 (also, 8, 16, ...), so you should be able to specify 4 cylinders per group, and quadruple your inodes. At the cost of space of course. You may be able to specify 2 or 1 also. I don't recall if some other bound eventually comes into play. When you play this game, you'll also have to reduce the number of sectors in the partition. newfs computed 175874 sectors for the partition based on 175 * 15 * 67. When you tell mkfs not to use some of the sectors, of course you'll have less space, so this number will be smaller. E.g. if you use 64 sectors per track, it will be 175 * 15 * 64. There's got to be a better way.
torek@elf.ee.lbl.gov (Chris Torek) (02/25/91)
(I have no idea why this is `Distribution: usa', but I left that in.) In article <VERBER.91Feb21171646@capemay.mps.ohio-state.edu> verber@pacific.mps.ohio-state.edu (Mark Verber) writes: >yes, newfs on SunOS 4.0.3 is busted. It is not entirely broken; it is merely uninformative. Newer `newfs'es will warn you when they must adjust some of your parameters (even if defaulted) in order to make the file system `fit'. >Under anything later than SunOS 4.0.3 (eg 4.1, 4.1.1) newfs does work, >and all you have to do is specify your preferred bytes/inodes with the >-i flag. This means they have picked up the 4.3-tahoe `fat fast file system' changes. (It only took how many years? :-) ) >The problem is that you can't tell mkfs directly how many inodes to >create. It figures the number for itself. There are about 5 numbers >that interact. Unfortunately, several of them have maximum or minimum >values, so you don't even get to specify them. Altogether, it looks >like mkfs was designed to make it as hard as possible to increase the >number of inodes. No, but mkfs was not designed to be easy to use; that is what `newfs' is for. Note that newfs has options to control all the arguments to mkfs. (Note also that mkfs is *gone* in 4.3-tahoe, having been merged right into newfs.) >In theory, you should be able to specify more than the usual number of >inodes per cylinder group. Newfs's `inodes per cg' defaults to the number that gives you the default 2048 bytes per inode, but on modern large disks this comes out to well over 2048 inodes per cg (since these disks have more than 4 MB per cg) given the default cylinger group size of 16 cylinders. In this particular example we have 67 sectors/track, 15 tracks/cylinder, and 16 cylinders, or 16080 sectors per cg, or 8232960 bytes per cg. To give each 2048 bytes one inode we would need 4020 inodes, almost twice as many as the hard limit. >Since you can't increase the number of inodes / cylinder group, you >have to increase the number of cylinder groups. Or, equivalently, decrease cylinders per cg (so that bytes per cg goes down). >So you have to decrease the number of cylinders per cylinder group. >This is an argument to mkfs, (and to newfs: -c). >so in some cases you can just specify it as 4 or 8. I've actually gotten >this to work sometimes. Unfortunately, sometimes mkfs won't let you >specify anything less than 16. Right. This has to do with the way the rotational layout tables are built. >Now things get hairy. The way mkfs computes the minimum number of >cylinders per group is sort of odd. It gets initialized to 16 (at >least for the disks I've seen). This 16 comes from (8192 bytes per block) / (512 bytes per sector) = 16 blocks per sector. >Then a loop is done which divides both cylinders per group and >sectors per cylinder by 2, until sectors per cylinder is odd. This is because the rotational tables `cycle' (repeat) for each time the sectors-per-cylinder is divisible by two. If spc is 48, for instance, the rotational tables for a complete cylinder group consist of one `base' table with 3 slots, repeated 16 times (3 * 16 = 48). If spc is 30, the table is made of two identical `base tables' with 15 slots each. The cylinder group must hold a complete base table. >If the number of sectors per cylinder starts out odd, of course this >loop stops immediately, and you get 16 cylinders per group. More precisely, you get (sectors per block) `cylinders per cycle'. This cyl/cycle count is used to round up another number (`mincpg count') which is always 1 or 2 for large disks: it is the number of cylinders needed to hold the `overhead' data for each cylinder group. Rounding 1 or 2 up to the nearest multiple of 16 always gives you 16. >I managed to fix things up by telling mkfs not to use all the sectors >on a track. In case this isn't obvious, what I'm doing is telling mkfs >to ignore some of my disk space. ... which in turn makes the rotational layout wrong, but makes the tables smaller. Another option is to reduce the file system block size, but this can goof up paging. >When you play this game, you'll also have to reduce the number of >sectors in the partition. Better yet, since you are going to lie about the geometry of the disk anyway, you might as well compute a new geometry that holds almost as much space. > /dev/rxd0e: 175874 sectors in 175 cylinders of 15 tracks, 67 sectors (175*15*67 = 175875, but we will use 175874....) Maintaining 15 tracks per cylinder, but going to 66 sectors per track, compute the new number of cylinders as: 175874 / (15 * 66) which gives 177, or (177 * 15 * 66) = 175230 sectors. 175874 - 175230 = 644 sectors `lost', or 322 kbytes. If you really need more inodes, claim you have 64 sectors per track, and: 175874 / (15 * 64) = 183 `new' cylinders which means you are going to use 183 * 15 * 64 = 175680 = 194 `lost' sectors, or a bit under 97 kbytes. Note that while you `lose' less space with the 64-sectors-per-track pseudo-geometry, the 66-sectors-per-track geometry is closer to reality and may well give noticeably better performance. (Then again, it may not.) >There's got to be a better way. Yes: put in the new file system code. :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov