From: "hch@lst.de" <hch@lst.de>
To: Goldwyn Rodrigues <RGoldwyn@suse.com>
Cc: "hch@lst.de" <hch@lst.de>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 07/19] iomap: use a srcmap for a read-modify-write I/O
Date: Tue, 10 Sep 2019 16:39:59 +0200 [thread overview]
Message-ID: <20190910143959.GB6794@lst.de> (raw)
In-Reply-To: <1568119693.12944.16.camel@suse.com>
On Tue, Sep 10, 2019 at 12:48:14PM +0000, Goldwyn Rodrigues wrote:
> > + if (srcmap.type)
> > + end = min(end, srcmap.offset + srcmap.length);
> > + if (pos + length > end)
> > + length = end - pos;
> >
>
>
> Yes, that looks more correct. However, can we be smart and not bother
> setting the minimum of end and srcmap.offset + srcmap.length if it is
> not required? ie in situations where end coincides with block boundary.
> Or if srcmap.length falls short, until the last block boundary of
> iomap?
>
> I did think about this scenario. This case is specific to CoW and
> thought this is best handled by filesystem's iomap_begin(). If this
> goes in, the filesystems would have to "falsify" srcmap length
> information to maximize the amount of I/O that goes in one iteration.
The problem is really that we can easily run over the srcmap (that's
what happened to me with XFS..) One thing you've done in btrfs that
I haven't done yet in XFS is to simply not bother with filling out
the srcmap if we don't need to (that is if the iteration is fully
page aligned in your patch set - the unshare op in this series will
complicate things a little). With that optimization the only case
where the shortening of the iteration that matters is if the start
is unaligned and needs a read-modify-write cycle, but the end is
aligned and beyond the end of the srcmap. Is that such an important
case?
>
> --
> Goldwyn---end quoted text---
next prev parent reply other threads:[~2019-09-10 14:40 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 18:27 iomap and xfs COW cleanups Christoph Hellwig
2019-09-09 18:27 ` [PATCH 01/19] iomap: better document the IOMAP_F_* flags Christoph Hellwig
2019-09-14 0:42 ` Allison Collins
2019-09-16 18:08 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 02/19] iomap: remove the unused iomap argument to __iomap_write_end Christoph Hellwig
2019-09-14 0:42 ` Allison Collins
2019-09-16 18:10 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 03/19] iomap: always use AOP_FLAG_NOFS in iomap_write_begin Christoph Hellwig
2019-09-16 18:11 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 04/19] iomap: ignore non-shared or non-data blocks in xfs_file_dirty Christoph Hellwig
2019-09-16 18:12 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 05/19] iomap: move the zeroing case out of iomap_read_page_sync Christoph Hellwig
2019-09-16 18:17 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 06/19] iomap: use write_begin to read pages to unshare Christoph Hellwig
2019-09-16 18:34 ` Darrick J. Wong
2019-09-30 11:07 ` Christoph Hellwig
2019-10-08 15:12 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 07/19] iomap: use a srcmap for a read-modify-write I/O Christoph Hellwig
2019-09-10 12:48 ` Goldwyn Rodrigues
2019-09-10 14:39 ` hch [this message]
2019-09-16 17:57 ` Darrick J. Wong
2019-09-16 18:42 ` Darrick J. Wong
2019-09-18 18:15 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 08/19] xfs: also call xfs_file_iomap_end_delalloc for zeroing operations Christoph Hellwig
2019-09-18 17:09 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 09/19] xfs: remove xfs_reflink_dirty_extents Christoph Hellwig
2019-09-18 17:17 ` Darrick J. Wong
2019-09-18 17:25 ` Christoph Hellwig
2019-09-18 17:31 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 10/19] xfs: pass two imaps to xfs_reflink_allocate_cow Christoph Hellwig
2019-09-18 17:26 ` Darrick J. Wong
2019-09-30 11:10 ` Christoph Hellwig
2019-09-09 18:27 ` [PATCH 11/19] xfs: refactor xfs_file_iomap_begin_delay Christoph Hellwig
2019-09-18 17:30 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 12/19] xfs: fill out the srcmap in iomap_begin Christoph Hellwig
2019-09-18 17:52 ` Darrick J. Wong
2019-10-01 6:26 ` Christoph Hellwig
2019-09-09 18:27 ` [PATCH 13/19] xfs: factor out a helper to calculate the end_fsb Christoph Hellwig
2019-09-14 0:42 ` Allison Collins
2019-09-18 17:55 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 14/19] xfs: split out a new set of read-only iomap ops Christoph Hellwig
2019-09-18 17:56 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 15/19] xfs: move xfs_file_iomap_begin_delay around Christoph Hellwig
2019-09-18 17:59 ` Darrick J. Wong
2019-09-30 11:14 ` Christoph Hellwig
2019-09-09 18:27 ` [PATCH 16/19] xfs: split the iomap ops for buffered vs direct writes Christoph Hellwig
2019-09-18 18:00 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 17/19] xfs: rename the whichfork variable in xfs_buffered_write_iomap_begin Christoph Hellwig
2019-09-14 0:42 ` Allison Collins
2019-09-18 18:00 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 18/19] xfs: cleanup xfs_iomap_write_unwritten Christoph Hellwig
2019-09-18 18:06 ` Darrick J. Wong
2019-09-09 18:27 ` [PATCH 19/19] xfs: improve the IOMAP_NOWAIT check for COW inodes Christoph Hellwig
2019-09-18 18:09 ` Darrick J. Wong
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=20190910143959.GB6794@lst.de \
--to=hch@lst.de \
--cc=RGoldwyn@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).