andy@syma.sussex.ac.uk (Andy Clews) (05/30/89)
We have a Symmetry S81 with two Swallow4 540Mb disks, running DYNIX 3.0.12. A few times in the last month, the partition containing our news spool area has suffered from inode overflow, even though only about 50% of the available space was used up. We decided to rebuild the file system with more inodes, using the "newfs" command (disk type m2344k). Trouble is, we find that no matter what number is supplied with the -i option to newsfs, the file system is rebuilt with exactly the same number as before (i.e. 36864 inodes on a 254Mb partition)! We asked for twice the current number of inodes. Anyone know what might be happening here? Is newfs simply ignoring the option or is something else overriding it? We ran newfs(8) also with the -v (verbose) option, and it appeared from the diagnostics that our requested number of inodes was not being passed on to mkfs. -- Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, ENGLAND JANET: andy@syma.sussex.ac.uk BITNET: andy%syma.sussex.ac.uk@uk.ac Voice: +44 273 606755 ext.2129
snoopy@sopwith.UUCP (Snoopy) (06/01/89)
In article <1033@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes: |Trouble is, we find that no matter what number is supplied with the -i |option to newsfs, the file system is rebuilt with exactly the same |number as before (i.e. 36864 inodes on a 254Mb partition)! We asked for |twice the current number of inodes. | |Anyone know what might be happening here? Is newfs simply ignoring the |option or is something else overriding it? We ran newfs(8) also with the |-v (verbose) option, and it appeared from the diagnostics that our |requested number of inodes was not being passed on to mkfs. Sounds odd. As a workaround, you could try running newfs -v to get all the magic numbers, and then running mkfs directly, tweaking the 'nbpi' argument as desired. Unless Sequent has done something unusual, newfs is merely a friendly front-end to mkfs. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________|
grr@cbmvax.UUCP (George Robbins) (06/02/89)
In article <193@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > In article <1033@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes: > > |Trouble is, we find that no matter what number is supplied with the -i > |option to newsfs, the file system is rebuilt with exactly the same > |number as before (i.e. 36864 inodes on a 254Mb partition)! We asked for > |twice the current number of inodes. > > Sounds odd. As a workaround, you could try running newfs -v to get > all the magic numbers, and then running mkfs directly, tweaking the > 'nbpi' argument as desired. Unless Sequent has done something unusual, > newfs is merely a friendly front-end to mkfs. With Ultrix (also 4.2 BSD based) I ran into the same problem maybe two years ago. It turned out there was an upper limit on the number of inodes for a given blocksize/fragsize and the only way to get more inodes was to diddle these values. There was also only a restriction on blocksize. Trying to use imaginative values resulted in them being silently ignored and the default values being used. It's been long enough I wouldn't swear by any of this, but maybe it'll point you in the right direction. Read the fine print in the manual and play with newfs -v and dumpfs to see what you're really getting... George -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
romain@pyramid.pyramid.com (Romain Kang) (06/03/89)
In article <1033@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes: |Trouble is, we find that no matter what number is supplied with the -i |option to newsfs, the file system is rebuilt with exactly the same |number as before (i.e. 36864 inodes on a 254Mb partition)! We asked for |twice the current number of inodes. In article <7041@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: |With Ultrix (also 4.2 BSD based) I ran into the same problem maybe two |years ago. It turned out there was an upper limit on the number of inodes |for a given blocksize/fragsize and the only way to get more inodes was to |diddle these values. There was also only a restriction on blocksize. | |Trying to use imaginative values resulted in them being silently ignored |and the default values being used. In <ufs/fs.h> (or <sys/fs.h> on non-NFS'd 4.3), you will find: /* * MAXIPG bounds the number of inodes per cylinder group, and * is needed only to keep the structure simpler by having the * only a single variable size element (the free bit map). * * N.B.: MAXIPG must be a multiple of INOPB(fs). */ #define MAXIPG 2048 /* max number inodes/cyl group */ I believe this is fixed in 4.3-Tahoe with the ``Fat Fast File System''. (Does anyone know whether SVr4 addresses this problem?) In the mean time, you can make your cylinder groups smaller by using the -c option on newfs. It does seem wastful to have 30+ cylinder groups on a 254MB partition. But you will get more inodes... -- Romain Kang Pyramid Technology Corporation "Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson