From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 5/5] xfs: revalidate imap properly before writeback delalloc conversion
Date: Fri, 18 Jan 2019 03:59:37 -0800 [thread overview]
Message-ID: <20190118115937.GD7807@infradead.org> (raw)
In-Reply-To: <20190117192004.49346-6-bfoster@redhat.com>
> + if (*seq != READ_ONCE(ifp->if_seq)) {
> + if (!xfs_iext_lookup_extent(ip, ifp, offset_fsb,
> + &icur, &timap) ||
> + timap.br_startoff > offset_fsb) {
> + ASSERT(0);
> + error = -EFSCORRUPTED;
> goto trans_cancel;
> }
> + xfs_trim_extent(imap, timap.br_startoff,
> + timap.br_blockcount);
> + count_fsb = imap->br_blockcount;
> + map_start_fsb = imap->br_startoff;
I very much disagree with this logic.
xfs_bmapi_write will always do a xfs_iext_lookup_extent for the
passed in blocks anyway. So this trimming logic should move into
xfs_bmapi_write to ensure it does the right thing, instead of papering
over the logic in xfs_bmapi_write in the caller with another lookup.
I think the improved XFS_BMAPI_DELALLOC handling in this patch:
http://git.infradead.org/users/hch/xfs.git/commitdiff/553fed9ce7695df081779c6a9a205af4142b2a06
is the right answer, as writeback really should only ever convert
existing delalloc extents, and I'd much rather rely on that rather than
piling hacks of hacks to feed the right range into a function that must
do a lookup in the extent tree anyway.
next prev parent reply other threads:[~2019-01-18 11:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 19:19 [PATCH v2 0/5] xfs: properly invalidate cached writeback mapping Brian Foster
2019-01-17 19:20 ` [PATCH v2 1/5] xfs: eof trim writeback mapping as soon as it is cached Brian Foster
2019-01-18 5:29 ` Allison Henderson
2019-01-18 11:47 ` Christoph Hellwig
2019-01-17 19:20 ` [PATCH v2 2/5] xfs: update fork seq counter on data fork changes Brian Foster
2019-01-18 5:30 ` Allison Henderson
2019-01-17 19:20 ` [PATCH v2 3/5] xfs: validate writeback mapping using data fork seq counter Brian Foster
2019-01-18 6:12 ` Allison Henderson
2019-01-18 11:50 ` Christoph Hellwig
2019-01-17 19:20 ` [PATCH v2 4/5] xfs: remove superfluous writeback mapping eof trimming Brian Foster
2019-01-18 6:48 ` Allison Henderson
2019-01-18 11:25 ` Brian Foster
2019-01-18 11:50 ` Christoph Hellwig
2019-01-17 19:20 ` [PATCH v2 5/5] xfs: revalidate imap properly before writeback delalloc conversion Brian Foster
2019-01-18 6:58 ` Allison Henderson
2019-01-18 11:59 ` Christoph Hellwig [this message]
2019-01-18 16:31 ` Christoph Hellwig
2019-01-18 18:39 ` Brian Foster
2019-01-20 12:45 ` Brian Foster
2019-01-21 15:51 ` Christoph Hellwig
2019-01-21 17:43 ` Brian Foster
2019-01-21 15:48 ` Christoph Hellwig
2019-01-21 17:42 ` Brian Foster
2019-01-22 17:14 ` Christoph Hellwig
2019-01-22 18:13 ` Brian Foster
2019-01-23 18:14 ` Christoph Hellwig
2019-01-23 18:40 ` 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=20190118115937.GD7807@infradead.org \
--to=hch@infradead.org \
--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 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.