linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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