inline_data status (e2fsprogs)

inline_data status (e2fsprogs)

[Pas]

Hello,

I hope this is the correct forum to ask these questions. (If not, then
sorry for the noise! Though then could you recommend where to ask
them?)


Is there any reason that inline_data is not a default enabled feature?
(The default inode size is already 256.
https://github.com/tytso/e2fsprogs/blob/dc5433647cb79bf1e7660f441c64330b3b8757cc/misc/mke2fs.conf.in#L14
)

Also, any particular reason that tune2fs cannot enable this feature?
("Setting filesystem feature 'inline_data' not supported.")

Finally, what are the dangers of using debugfs to enable the feature
flag? (As suggested here https://unix.stackexchange.com/a/309260/4003
)

Thanks,
Pas

Re: inline_data status (e2fsprogs)

[Theodore Y. Ts'o]

On Sat, Sep 14, 2019 at 08:06:04PM +0200, Pas wrote:
> 
> I hope this is the correct forum to ask these questions. (If not, then
> sorry for the noise! Though then could you recommend where to ask
> them?)

There are some known issues with with the inline_data feature; in
particular, it violates some of the jbd2 rules about how to jorunal
data blocks.  As such, bad things(tm) can happen on crash recovery.
For the most part it works OK for the original intended use case, was
for bigalloc file systems where there was a desire to handle small
directories more efficiently, which was how the developer who created
the feature used said feature.  I didn't realize this particular
rather serious bug until after the feature went into the kernel, and
it's been on my todo list to fix; I just haven't had the time.

It doesn't happen all that often; you need to start files that are
small enough such that they can fit in an inline_data file, and then
grow them via an appending write so that they need to be shifted to an
block allocated file, and then force an unclean shutdown at an
inopportune time.

But yeah, there is a good reason why it's not a default-enabled
feature.  It also generally doesn't buy you much for most file system
workloads, so it hasn't been high on my priority list to fix.

Regards,

					- Ted

Re: inline_data status (e2fsprogs)

[Pas]

Thanks for the blazing fast and detailed reply!

Am I correct assuming that the jbd2 problem is only (mostly?) relevant
in case of data=journal mode?

> It also generally doesn't buy you much for most file system
workloads, so it hasn't been high on my priority list to fix.

Completely understandable. I wasn't really hunting for those juice
performance bits, however it seemed like a nice optimization that's in
the kernel for quite long, plus enabling it is just a bit flip, then
why not? But then I haven't found anything conclusive on it.

Thanks again for clearing things up!

Pas

On Sun, 15 Sep 2019 at 01:28, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Sat, Sep 14, 2019 at 08:06:04PM +0200, Pas wrote:
> >
> > I hope this is the correct forum to ask these questions. (If not, then
> > sorry for the noise! Though then could you recommend where to ask
> > them?)
>
> There are some known issues with with the inline_data feature; in
> particular, it violates some of the jbd2 rules about how to jorunal
> data blocks.  As such, bad things(tm) can happen on crash recovery.
> For the most part it works OK for the original intended use case, was
> for bigalloc file systems where there was a desire to handle small
> directories more efficiently, which was how the developer who created
> the feature used said feature.  I didn't realize this particular
> rather serious bug until after the feature went into the kernel, and
> it's been on my todo list to fix; I just haven't had the time.
>
> It doesn't happen all that often; you need to start files that are
> small enough such that they can fit in an inline_data file, and then
> grow them via an appending write so that they need to be shifted to an
> block allocated file, and then force an unclean shutdown at an
> inopportune time.
>
> But yeah, there is a good reason why it's not a default-enabled
> feature.  It also generally doesn't buy you much for most file system
> workloads, so it hasn't been high on my priority list to fix.
>
> Regards,
>
>                                         - Ted