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.
-- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
