linux-ext4 - Re: inline_data status (e2fsprogs)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190914232801.GD19710@mit.edu>
Date:   Sat, 14 Sep 2019 19:28:01 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Pas <pas@...g.hu>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: inline_data status (e2fsprogs)

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