From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Whitney <enwlinux@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: disable dioread_nolock whenever delayed allocation is disabled
Date: Thu, 26 Mar 2020 10:57:57 -0400 [thread overview]
Message-ID: <20200326145757.GT53396@mit.edu> (raw)
In-Reply-To: <20200319150028.24592-1-enwlinux@gmail.com>
On Thu, Mar 19, 2020 at 11:00:28AM -0400, Eric Whitney wrote:
> The patch "ext4: make dioread_nolock the default" (244adf6426ee) causes
> generic/422 to fail when run in kvm-xfstests' ext3conv test case. This
> applies both the dioread_nolock and nodelalloc mount options, a
> combination not previously tested by kvm-xfstests. The failure occurs
> because the dioread_nolock code path splits a previously fallocated
> multiblock extent into a series of single block extents when overwriting
> a portion of that extent. That causes allocation of an extent tree leaf
> node and a reshuffling of extents. Once writeback is completed, the
> individual extents are recombined into a single extent, the extent is
> moved again, and the leaf node is deleted. The difference in block
> utilization before and after writeback due to the leaf node triggers the
> failure.
>
> The original reason for this behavior was to avoid ENOSPC when handling
> I/O completions during writeback in the dioread_nolock code paths when
> delayed allocation is disabled. It may no longer be necessary, because
> code was added in the past to reserve extra space to solve this problem
> when delayed allocation is enabled, and this code may also apply when
> delayed allocation is disabled. Until this can be verified, don't use
> the dioread_nolock code paths if delayed allocation is disabled.
>
> Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Applied, thanks.
- Ted
prev parent reply other threads:[~2020-03-26 14:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 15:00 [PATCH] ext4: disable dioread_nolock whenever delayed allocation is disabled Eric Whitney
2020-03-26 14:57 ` 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=20200326145757.GT53396@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.