issues Ext4 inode flags

[Kirk McKusick]

> Date: Thu, 16 Jan 2014 11:31:29 -0500
> From: Pedro Giffuni <pfg at freebsd.org>
> To: fs at freebsd.org
> Subject: issues Ext4 inode flags
> 
> Hello;
> 
> I have been working around some issues in our ext2/3/4 support and
> there is this problem:
> 
> Before r260545 we were passing the Ext2/3/4 flags with some
> conversion into the inode i_flags. Since our system flags don't
> match the linux flags this actually introduced a lot of garbage.
> 
> r260545 cut the garbage completely but it also does not pass
> the EXT4 flags of which we need two for our ext4 ro implementation:
> EXT4_EXTENTS and EXT4_INDEX. We also use EXT4_HUGE_FILE
> but we can read that directly from the dinode.
> 
> The flags are pretty specific to Ext4 so it doesn't make sense to add
> them to to our stat.h and include them in the inode conversion routines.
> 
> I have two options:
> 
> 1- Pass only the flags that we need and clear the rest.
> Obviously a hack, this seems this is somewhat safer and has
> worked so far as it only applies to the read-only ext4. There is
> still some space for collision:
> EXT4_INDEX     --> UF_READONLY
> EXT4_EXTENTS --> UF_HIDDEN
> 
> The patch is here:
> http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-passinode.patch
> 
> 2- Create a field in the inode specifically to carry the Ext4_* inode flags.
> This. of course, costs memory for a feature that is rarely used but
> is cleaner and may be useful if we ever add write support.
> 
> The proof-of-concept patch is here:
> http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-inode.patch
> 
> I am inclining towards option (1): it's rather hackish but it
> just works and I don't forsee us doing much efforts to support
> ext4 much better in the future.
> 
> Both patches re-enable dirindex for testing purposes.
> Comments and testing are welcome.
> 
> Pedro.

Given your belief that write support for ext4 is unlikely, I agree
with your option 1 preference. However, if write support is to be
added for ext4, then I think that option 2 would be better. In
theory, it is possible to migrate to option 2 later if/when write
support is added assuming you have a version number that you can
bump.

	Kirk McKusick