public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: only remap the written blocks in xfs_reflink_end_cow_extent
Date: Mon, 16 Oct 2023 17:56:15 -0700	[thread overview]
Message-ID: <20231017005615.GA11424@frogsfrogsfrogs> (raw)
In-Reply-To: <20231016161019.GA8089@lst.de>

On Mon, Oct 16, 2023 at 06:10:19PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 16, 2023 at 08:48:27AM -0700, Darrick J. Wong wrote:
> > Hmm.  xfs_prepare_ioend converts unwritten cowfork extents to written
> > prior to submit_bio.  So I guess you'd have to trick writeback into
> > issuing totally separate bios for the single mapping.
> 
> Yes.  Hitting IOEND_BATCH_SIZE seems like the least difficult one
> to hit, but even that would require work.
> 
> > Then you'd have
> > to delay the bio for the higher offset part of the mapping while
> > allowing the bio for the lower part to complete, at which point it would
> > convey the entire mapping to the data fork.
> 
> Shouldn't really matter which side is faster.
> 
> > Then you'd have to convince
> > the kernel to reread the contents from disk.  I think that would be hard
> > since the folios for the incomplete writeback are still uptodate and
> > marked for writeback.  directio will block trying to flush and
> > invalidate the cache, and buffered io will read the pagecache.
> 
> I don't think on a live kernel it is possible.  But if one of the
> two bios completed before the other one, and power failed just inbetween.

Ooooh, yeah.  That could happen if the ioend metadata update gets
written to the log device and the system crashes before that other bio
even gets a chance to execute.

--D

      reply	other threads:[~2023-10-17  0:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-16 15:28 [PATCH] xfs: only remap the written blocks in xfs_reflink_end_cow_extent Christoph Hellwig
2023-10-16 15:48 ` Darrick J. Wong
2023-10-16 16:10   ` Christoph Hellwig
2023-10-17  0:56     ` Darrick J. Wong [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=20231017005615.GA11424@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox