Well, apparently I didn't read my manpages closely enough...thanks go to: David Glass Casper Dik Thorfinn Rasmussen Richard Lacroix All of which pointed at the -m otion to mkfs: mkfs -m /dev/rdsk/c0t1d0s7 However, some of the ouput doesn't make sense (Thor mentioned he got nbpi=8273 and we've gotten nbpi=4114 and nbpi=8227). thanks folks =G= Galen Johnson wrote: > I'm not sure I made myself clear in this question..what I'm looking > for is an easy way (yes, I know I can do the math but PHB don't always > believe the math especially when they don't know the diff between > block size and number of bytes per inode). I'm trying to find a > command that will give me back (basically) what XX is below: > > newfs -i XX /dev/dsk/c0t1d0s7 > > I had hoped that the fstyp info would have the necessary information. > I've gotten couple (literally) of replies. One of which recommended > 'df -F ufs -o i' which only gives usage info (and I forgot to include > it in my previous email as well). Another mentioned that they are 128 > bytes each and referenced a header file, ufs_inode.h. I read through > several header files and in the ufs_trans.h there is a reference to > ':#define INODESIZE (sizeof (struct dinode) + > HEADERSIZE)'. I know this info has to be in the superblock somewhere > but just not sure how to draw it out. > > As I had mentioned solaris has some defaults for filesystems and bytes > per inode unless you override them when creating a filesystem (which > I'm sure most of us have done). Here is the relevant info from the > man page for newfs: > > -i nbpi > The number of bytes per inode. This specifies > the density of inodes in the file system. The > number is divided into the total size of the > file system to determine the fixed number of > inodes to create. It should reflect the expected > average size of files in the file system. If > fewer inodes are desired, a larger number should > be used; to create more inodes a smaller number > should be given. The default for nbpi is as fol- > lows:. > > Disk size Density > > -1GB 2048 > -2GB 4096 > -3GB 6144 > 3GB- 8192 > > The quest goes on... > > =G= > > Galen Johnson wrote: > >> A recent question in regardss to inodes came across the list (this >> week I think). I believe they want to know how large their inodes >> were. I've been looking and couldn't really find a good answer for >> myself as the answers they were given don't seem to make sense. >> >> newfs -Nv /dev/rdsk/blah >> >> This doesn't make sense as it will only give you what it _would_ do >> if you were to create a filesystem with that command. >> >> netstat -k >> >> If the inode info is in that output I'm hard pressed to find it. >> >> This was what I did... >> >> ftyp -v /dev/dsk/c0t1d0s7 | head -20 >> >> with the following output... >> >> fstyp -v /dev/dsk/c0t1d0s7 | head -20 >> ufs >> magic 11954 format dynamic time Thu Nov 14 22:58:27 2002 >> sblkno 16 cblkno 24 iblkno 32 dblkno 768 >> sbsize 2048 cgsize 5120 cgoffset 40 cgmask 0xffffffe0 >> ncg 86 size 2077080 blocks 2012390 >> bsize 8192 shift 13 mask 0xffffe000 >> fsize 1024 shift 10 mask 0xfffffc00 >> frag 8 shift 3 fsbtodb 1 >> minfree 3% maxbpg 2048 optim time >> maxcontig 16 rotdelay 0ms rps 90 >> csaddr 768 cssize 2048 shift 9 mask 0xfffffe00 >> ntrak 19 nsect 80 spc 1520 ncyl 2733 >> cpg 32 bpg 3040 fpg 24320 ipg 5888 >> nindir 2048 inopb 64 nspf 2 >> nbfree 165254 ndir 944 nifree 492297 nffree 4827 >> cgrotor 72 fmod 0 ronly 0 logbno 0 >> fs_reclaim is not set >> file system state is valid, fsclean is 2 >> blocks available in each rotational position >> cylinder number 0: >> Broken Pipe >> Unknown_fstyp (no matches) >> >> Myself and another admin have more or less convinced ourselfs that >> the 'nindir 2048' is actually giving us the inode size but I can't >> find any prove to back up our hypothesis (for some reason I can't get >> to sunsolve nor docs.sun.com. the trace dies at their router). >> >> Any input will be appreciated. I'll summarize. >> >> =G= >> _______________________________________________ >> sunmanagers mailing list >> sunmanagers@sunmanagers.org >> http://www.sunmanagers.org/mailman/listinfo/sunmanagers > > _______________________________________________ > sunmanagers mailing list > sunmanagers@sunmanagers.org > http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Fri Nov 15 10:14:32 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:58 EST