From: Carlos Maiolino <cmaiolino@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-fsdevel@vger.kernel.org, adilger@dilger.ca,
jaegeuk@kernel.org, darrick.wong@oracle.com, miklos@szeredi.hu,
rpeterso@redhat.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/9] fs: Enable bmap() function to properly return errors
Date: Tue, 20 Aug 2019 13:36:20 +0200 [thread overview]
Message-ID: <20190820113619.qhvf44wyc4b2emw3@pegasus.maiolino.io> (raw)
In-Reply-To: <20190814111435.GB1885@lst.de>
On Wed, Aug 14, 2019 at 01:14:35PM +0200, Christoph Hellwig wrote:
> Just curious from looking this again - shoudn't the 0 block be turned
> into an error by the bmap() function? At least for the legacy ->bmap
> case so that we don't have to carry this cruft around.
I don't think so, this patch does not change the bmap interface on the
filesystems itself, and at this point, we don't have a way to distinguish
between a hole and an error from the filesystem's bmap() interface. The main
idea of enabling bmap() to return errors, was to take advantage of the fiemap
errors (in another patch in this series).
Although, I do agree that this also opens the possibility to change the
interface itself, and make ->bmap calls to really return errors, but this will
require a bigger change in all users of ->bmap(). I can work on that, but I'd
prefer to change this interface in another patchset, after this one is merged.
So, we can work only on those filesystems where ->bmap() will still be a thing.
Cheers.
--
Carlos
next prev parent reply other threads:[~2019-08-20 11:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 8:27 [PATCH 0/9 V5] New ->fiemap infrastructure and ->bmap removal Carlos Maiolino
2019-08-08 8:27 ` [PATCH 1/9] fs: Enable bmap() function to properly return errors Carlos Maiolino
2019-08-08 21:24 ` kbuild test robot
2019-08-14 11:14 ` Christoph Hellwig
2019-08-20 11:36 ` Carlos Maiolino [this message]
2019-08-08 8:27 ` [PATCH 2/9] cachefiles: drop direct usage of ->bmap method Carlos Maiolino
2019-08-14 11:15 ` Christoph Hellwig
2019-08-20 11:57 ` Carlos Maiolino
2019-08-20 12:50 ` David Howells
2019-08-29 7:13 ` Christoph Hellwig
2019-08-30 16:17 ` David Howells
2019-08-30 16:59 ` Christoph Hellwig
2019-08-31 0:45 ` David Howells
2019-09-05 22:44 ` Dave Chinner
2019-08-20 13:31 ` David Howells
2019-08-08 8:27 ` [PATCH 3/9] ecryptfs: drop direct calls to ->bmap Carlos Maiolino
2019-08-08 22:50 ` kbuild test robot
2019-08-08 8:27 ` [PATCH 4/9] fibmap: Use bmap instead of ->bmap method in ioctl_fibmap Carlos Maiolino
2019-08-08 20:38 ` kbuild test robot
2019-08-14 11:01 ` Carlos Maiolino
2019-08-14 11:08 ` Christoph Hellwig
2019-08-08 8:27 ` [PATCH 5/9] fs: Move start and length fiemap fields into fiemap_extent_info Carlos Maiolino
2019-08-08 20:21 ` kbuild test robot
2019-08-08 8:27 ` [PATCH 6/9] iomap: Remove length and start fields from iomap_fiemap Carlos Maiolino
2019-08-08 8:27 ` [PATCH 7/9] fiemap: Use a callback to fill fiemap extents Carlos Maiolino
2019-08-09 0:04 ` kbuild test robot
2019-08-14 11:16 ` Christoph Hellwig
2019-08-08 8:27 ` [PATCH 8/9] Use FIEMAP for FIBMAP calls Carlos Maiolino
2019-08-08 8:27 ` Carlos Maiolino
2019-08-09 1:56 ` kbuild test robot
2019-08-14 11:18 ` Christoph Hellwig
2019-08-20 13:01 ` Carlos Maiolino
2019-08-29 7:15 ` Christoph Hellwig
2019-09-10 12:28 ` Carlos Maiolino
2019-09-16 15:58 ` Darrick J. Wong
2019-08-08 8:27 ` [PATCH 9/9] xfs: Get rid of ->bmap Carlos Maiolino
-- strict thread matches above, loose matches on Subject: below --
2019-09-11 13:43 [PATCH 0/9 V6] New ->fiemap infrastructure and ->bmap removal Carlos Maiolino
2019-09-11 13:43 ` [PATCH 1/9] fs: Enable bmap() function to properly return errors Carlos Maiolino
2019-07-31 14:12 [PATCH 0/9 V4] New ->fiemap infrastructure and ->bmap removal Carlos Maiolino
2019-07-31 14:12 ` [PATCH 1/9] fs: Enable bmap() function to properly return errors Carlos Maiolino
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=20190820113619.qhvf44wyc4b2emw3@pegasus.maiolino.io \
--to=cmaiolino@redhat.com \
--cc=adilger@dilger.ca \
--cc=darrick.wong@oracle.com \
--cc=hch@lst.de \
--cc=jaegeuk@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rpeterso@redhat.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;
as well as URLs for NNTP newsgroup(s).