Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 2014 22:11:45 -0500
From:      Pedro Giffuni <pfg@FreeBSD.org>
To:        Kirk McKusick <mckusick@mckusick.com>
Cc:        fs@freebsd.org
Subject:   Re: issues Ext4 inode flags 
Message-ID:  <08A6A8AC-3994-4C14-926B-BB020E7BA8BF@FreeBSD.org>
In-Reply-To: <201401170207.s0H27NeY032950@chez.mckusick.com>
References:  <201401170207.s0H27NeY032950@chez.mckusick.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello Kirk;

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

>> Date: Thu, 16 Jan 2014 11:31:29 -0500
>> From: Pedro Giffuni <pfg@freebsd.org>
>> To: fs@freebsd.org
>> Subject: issues Ext4 inode flags
>>=20
>> Hello;
>>=20
>> I have been working around some issues in our ext2/3/4 support and
>> there is this problem:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> I have two options:
>>=20
>> 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
>>=20
>> The patch is here:
>> http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-passinode.patch
>>=20
>> 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.
>>=20
>> The proof-of-concept patch is here:
>> http://people.freebsd.org/~pfg/patches/ext2fs/ext2fs-inode.patch
>>=20
>> 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.
>>=20
>> Both patches re-enable dirindex for testing purposes.
>> Comments and testing are welcome.
>>=20
>> Pedro.
>=20
> 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.
>=20

Thank you for the feedback.

For the record, I think adding Ext4 write support is possible and it =
doesn=92t 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.=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08A6A8AC-3994-4C14-926B-BB020E7BA8BF>