On Thursday July 20, manfred@colorfullife.com wrote:
> On Thu, 20 Jul 2000, Linus Torvalds wrote:
>
> > I wasn't serious.
> >
> > It was a comment to your "if you have a million inodes it's a lot of bits"
> > comment.
> >
> > Considering that the inode is probably 200+ bytes, the million inodes case
> > is fairly scary. And the 4 bytes won't be that noticeable..
> >
>
> around 416 bytes [just cat /proc/slabinfo, the third number is size,
> rounded to cache line size]
>
> > You'd save more by making the quota stuff go away when quotas aren't
> > enabled..
> >
>
> Or by removing a superflous variable in each buffer head: the kiobuf code
> adds it's own callback parameter instead of using the generic one.
Ok, I'll bite...
Only one of i_rdev and i_size are needed at a time, so we could union
them.
i_zombie is only needed on diretories. i_flock is (I suspect) not
needed on directories, so we can union them. They can be in the same
union as i_pipe and i_bdev I suspect (hmmm. can you lock range of a
block device?)
i_blksize is constant across filesystems, so it can be moved to the
superblock (I suspect that I am actualy wrong here. There is probably
a good reason for it to be in the inode, but I cannot pick it).
i_state is a long, and has 4 bits defined! We should make it a char
and put it next to i_sock. Would save 7 bytes on an alpha.
Of the 356 bytes in struct inode (on i386) 132 are in the union at the
end.
The largest few components of these are:
nfs_i 132
ext2_i 116
efs_i 104
affs_i 104
ufs_i 100
For people not using client-nfs, being able to compile witout it would
save 16 bytes per inode, 4%.
Turning our attention to ext2, as ext2 doesn't actually do
fragmentation of blocks, i_frag_no and i_frag_size could be removed
saving 2 bytes. not_used_1 could be removed (PLEASE!!) saving 4
bytes.
All up, I suspect we could trim 10% off the inode size which might
almost be considered to be significant????
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:14 EST