From: Christoph Hellwig <hch@lst.de>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/7] xfs: handle zeroing in xfs_file_iomap_begin_delay
Date: Mon, 1 Oct 2018 16:46:18 +0200 [thread overview]
Message-ID: <20181001144618.GA5831@lst.de> (raw)
In-Reply-To: <20181001142005.GE53694@bfoster>
On Mon, Oct 01, 2018 at 10:20:05AM -0400, Brian Foster wrote:
> > eof = !xfs_iext_lookup_extent(ip, ifp, offset_fsb, &icur, &got);
> > - if (!eof && got.br_startoff <= offset_fsb) {
> > - if (xfs_is_reflink_inode(ip)) {
> > + if (eof)
> > + got.br_startoff = maxbytes_fsb;
>
> What's the purpose of this? Can't we just continue to use eof in the
> logic below and report holes up through the requested range (offset +
> length) just like the other branch does (via xfs_bmapi_read())?
Setting the startblock makes the code a lot simpler. But yes,
we could limit the hole to the reporting range.
>
> > + if (got.br_startoff <= offset_fsb) {
> > + if (xfs_is_reflink_inode(ip) &&
> > + ((flags & IOMAP_WRITE) ||
> > + got.br_state != XFS_EXT_UNWRITTEN)) {
>
> I think a small comment is useful here due to the implicit logic. For
> example:
>
> /* reservation is required for writes and zeroing over normal extents */
Ok.
next prev parent reply other threads:[~2018-10-01 21:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-01 12:37 delalloc and reflink fixes & tweaks V2 Christoph Hellwig
2018-10-01 12:37 ` [PATCH 1/7] xfs: remove XFS_IO_INVALID Christoph Hellwig
2018-10-01 14:19 ` Brian Foster
2018-10-01 12:37 ` [PATCH 2/7] xfs: always allocate blocks as unwritten for file data Christoph Hellwig
2018-10-01 14:19 ` Brian Foster
2018-10-01 12:37 ` [PATCH 3/7] xfs: handle zeroing in xfs_file_iomap_begin_delay Christoph Hellwig
2018-10-01 14:20 ` Brian Foster
2018-10-01 14:46 ` Christoph Hellwig [this message]
2018-10-01 12:37 ` [PATCH 4/7] xfs: remove the unused shared argument to xfs_reflink_reserve_cow Christoph Hellwig
2018-10-01 14:26 ` Brian Foster
2018-10-01 12:37 ` [PATCH 5/7] xfs: remove the unused trimmed argument from xfs_reflink_trim_around_shared Christoph Hellwig
2018-10-01 14:26 ` Brian Foster
2018-10-01 12:37 ` [PATCH 6/7] xfs: fix fork selection in xfs_find_trim_cow_extent Christoph Hellwig
2018-10-01 14:27 ` Brian Foster
2018-10-01 12:37 ` [PATCH 7/7] xfs: print dangling delalloc extents Christoph Hellwig
2018-10-01 14:27 ` Brian Foster
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=20181001144618.GA5831@lst.de \
--to=hch@lst.de \
--cc=bfoster@redhat.com \
--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).