Re: Default ext inode size

[Phillip Susi <psusi@cfl.rr.com>]

Theodore Tso wrote:
> That's the main one.  The other benefit is that ext4 uses a bigger
> inode to store some extra fields such as the file creation time,
> nanosecond timestamps, and the 64-bit version number neede which is
> used for NFSv4's client-side caching.

What about ext3?  Does it do the same thing with the larger inode?  Does 
it get more block pointers or room for block extent lists ( in ext4 )? 
Are the higher resolution timestamps used by default if the inode is 
large, or is there a compatibility bit and/or mount option that needs set?

> The big user of extended attribute is SELinux, Samba, and Beagle.
> Since a number of distributions are now starting to enable SELinux by
> default (for better or for worse), it makes a big difference from a
> performance perspective for those distributions.

Does it actually help performance to store the ae in the inode?  I would 
think it would not make much difference if many files have the same 
attributes, then the shared ea block would be cached.  Storing the ea in 
the inode seems like it duplicates a lot of data and means a given 
amount of ram could only cache half as many inodes as with the normal 
size, which would lead to less cache hits and more disk IO.

> I can't imagine that it would be that hard to fix the Windows driver
> to be able to support 258 byte inodes.  It should be a one- or
> two-line fix, for those people who care.

Probably, but it is an example ( and there probably are others ) of 
problems caused by changing the default, so I'm trying to understand why 
ext3 was disturbed in this way rather than just make 256 byte inodes the 
default for only ext4.