From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Pas <pas@zomg.hu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: inline_data status (e2fsprogs)
Date: Sat, 14 Sep 2019 19:28:01 -0400 [thread overview]
Message-ID: <20190914232801.GD19710@mit.edu> (raw)
In-Reply-To: <CAF1H-TADHtpDtdL++Vk1FLAL7jJbOOifnN+7taDXpVkjYrbsgA@mail.gmail.com>
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
next prev parent reply other threads:[~2019-09-14 23:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-14 18:06 inline_data status (e2fsprogs) Pas
2019-09-14 23:28 ` Theodore Y. Ts'o [this message]
2019-09-16 9:20 ` Pas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190914232801.GD19710@mit.edu \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=pas@zomg.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).