Mikal talks about Ted talking about Tridge talking about how larger inodes can improve samba4 performance. Well, not just Samba4. Beagle and SELinux are also common heaver users of extended attributes which can often be stored inside the inode (e.g. on XFS).

There used to be the case where the Fedora installer would run mkfs.xfs with the default options and enable SELinux. Turns out this setup is great for systems without SELinux but the xattrs were large enough to require more space than what could fit in the inode, causing an extra block per inode to be allocated for xattrs. Not exactly space efficient.

The same can happen with Beagle. So if you’re using SELinux and/or Beagle and/or Samba4 – large inodes are probably going to be a winner for you.

I think we’re getting to the time where xattrs are popping up here there and everywhere for all sorts of applications and we’re going to have to find good (and efficient) ways of storing them.

I’m increasingly warming up to the idea of variable sized inodes. For a FS like XFS this could be done per group of inodes (XFS typically will, when more inodes are needed, create 64 inodes at once). File systems such as ext3 don’t really have this option as there is an inode table that is fixed and created at mkfs time. Although Ted has some interesting ideas for ext4 in this regard.

I’m sure Val Henson would have some interesting ideas for ChunkFS too…  a very interesting concept that I’ve been thinking about the possibility of retrofitting into existing systems (which I don’t think is that silly).

It would be great for some of the XFS dudes to write about the parallelising of checking an XFS file system.