issues Ext4 inode flags

[Pedro Giffuni]

Hello Kirk;

Il giorno 16/gen/2014, alle ore 21:07, Kirk McKusick <mckusick at mckusick.com> ha scritto:

>> 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.
> 

Thank you for the feedback.

For the record, I think adding Ext4 write support is possible and it doesn’t seem particularly difficult (option 2 took me only a few minutes to implement). The design is somewhat poor and not really meant for portability though and there are other filesystems around that are much more interesting.

As with anything where decisions are taken elsewhere, the version number is not an option we can use, the best I can do is document things well so that anyone with the time and motivation will not have to find out the hard way.

Cheers,

Pedro.