From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Whitney <enwlinux@gmail.com>
Cc: <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: fix bigalloc cluster freeing when hole punching under load
Date: Fri, 1 Mar 2019 00:00:09 -0500 [thread overview]
Message-ID: <20190301050009.GA8234@mit.edu> (raw)
In-Reply-To: <20190227220204.31804-1-enwlinux@gmail.com>
On Wed, Feb 27, 2019 at 05:02:04PM -0500, Eric Whitney wrote:
> Ext4 may not free clusters correctly when punching holes in bigalloc
> file systems under high load conditions. If it's not possible to
> extend and restart the journal in ext4_ext_rm_leaf() when preparing to
> remove blocks from a punched region, a retry of the entire punch
> operation is triggered in ext4_ext_remove_space(). This causes a
> partial cluster to be set to the first cluster in the extent found to
> the right of the punched region. However, if the punch operation
> prior to the retry had made enough progress to delete one or more
> extents and a partial cluster candidate for freeing had already been
> recorded, the retry would overwrite the partial cluster. The loss of
> this information makes it impossible to correctly free the original
> partial cluster in all cases.
>
> This bug can cause generic/476 to fail when run as part of
> xfstests-bld's bigalloc and bigalloc_1k test cases. The failure is
> reported when e2fsck detects bad iblocks counts greater than expected
> in units of whole clusters and also detects a number of negative block
> bitmap differences equal to the iblocks discrepancy in cluster units.
>
> Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Thanks, applied.
- Ted
prev parent reply other threads:[~2019-03-01 5:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-27 22:02 [PATCH] ext4: fix bigalloc cluster freeing when hole punching under load Eric Whitney
2019-03-01 5:00 ` Theodore Y. Ts'o [this message]
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=20190301050009.GA8234@mit.edu \
--to=tytso@mit.edu \
--cc=enwlinux@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.