From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Long Li <leo.lilong@huawei.com>,
brauner@kernel.org, djwong@kernel.org, cem@kernel.org,
linux-xfs@vger.kernel.org, yi.zhang@huawei.com,
houtao1@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH v2 1/2] iomap: fix zero padding data issue in concurrent append writes
Date: Fri, 15 Nov 2024 07:01:58 +1100 [thread overview]
Message-ID: <ZzZXNoOsFRqcd6ge@dread.disaster.area> (raw)
In-Reply-To: <ZzY7r1l5dpBw7UsY@bfoster>
On Thu, Nov 14, 2024 at 01:04:31PM -0500, Brian Foster wrote:
> On Thu, Nov 14, 2024 at 10:34:26AM +0800, Long Li wrote:
> > On Wed, Nov 13, 2024 at 11:13:49AM -0500, Brian Foster wrote:
> ISTM that for the above merge scenario to happen we'd either need
> writeback of the thread 1 write to race just right with the thread 2
> write, or have two writeback cycles where the completion of the first is
> still pending by the time the second completes. Either of those seem far
> less likely than either writeback seeing i_size == 8k from the start, or
> the thread 2 write completing sometime after the thread 1 ioend has
> already been completed. Hm?
I think that this should be fairly easy to trigger with concurrent
sub-block buffered writes to O_DSYNC|O_APPEND opened files. The fact
we drop the IOLOCK before calling generic_write_sync() to flush the
data pretty much guarantees that there will be IO in flight whilst
other write() calls have extended the file in memory and are then
waiting for the current writeback on the folio to complete before
submitting their own writeback IO.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2024-11-14 20:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-13 9:19 [PATCH v2 1/2] iomap: fix zero padding data issue in concurrent append writes Long Li
2024-11-13 9:19 ` [PATCH v2 2/2] xfs: clean up xfs_end_ioend() to reuse local variables Long Li
2024-11-18 6:57 ` Christoph Hellwig
2024-11-13 9:44 ` [PATCH v2 1/2] iomap: fix zero padding data issue in concurrent append writes Carlos Maiolino
2024-11-13 11:38 ` Long Li
2024-11-13 12:56 ` Carlos Maiolino
2024-11-13 16:13 ` Brian Foster
2024-11-14 2:34 ` Long Li
2024-11-14 18:04 ` Brian Foster
2024-11-14 20:01 ` Dave Chinner [this message]
2024-11-15 14:03 ` Brian Foster
2024-11-15 11:53 ` Long Li
2024-11-15 13:46 ` Brian Foster
2024-11-19 1:35 ` Long Li
2024-11-18 6:56 ` Christoph Hellwig
2024-11-18 14:26 ` Brian Foster
2024-11-20 9:05 ` Christoph Hellwig
2024-11-20 13:50 ` Brian Foster
2024-11-21 5:49 ` Christoph Hellwig
2024-11-19 8:35 ` Long Li
2024-11-19 12:13 ` Brian Foster
2024-11-19 13:46 ` Long Li
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=ZzZXNoOsFRqcd6ge@dread.disaster.area \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=houtao1@huawei.com \
--cc=leo.lilong@huawei.com \
--cc=linux-xfs@vger.kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
/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