From: Galen Johnson (gjohnson@trantor.org)
Date: Fri Nov 15 2002 - 09:33:33 EST
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
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:25:17 EDT