From: Carlos Maiolino <cmaiolino@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-fsdevel@vger.kernel.org, adilger@dilger.ca,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 9/9] xfs: Get rid of ->bmap
Date: Mon, 23 Sep 2019 10:52:49 +0200 [thread overview]
Message-ID: <20190923085248.ttf6ruum7dp3qqjd@pegasus.maiolino.io> (raw)
In-Reply-To: <20190918161241.GW2229799@magnolia>
On Wed, Sep 18, 2019 at 09:12:41AM -0700, Darrick J. Wong wrote:
> On Wed, Sep 18, 2019 at 03:24:36PM +0200, Christoph Hellwig wrote:
> > On Wed, Sep 18, 2019 at 10:13:04AM +0200, Carlos Maiolino wrote:
> > > All checks are now made in the caller, bmap_fiemap() based on the filesystem's
> > > returned flags in the fiemap structure. So, it will decide to pass the result
> > > back, or just return -EINVAL.
> > >
> > > Well, there is no way for iomap (or bmap_fiemap now) detect the block is in a
> > > realtime device, since we have no flags for that.
> > >
> > > Following Christoph's line of thought here, maybe we can add a new IOMAP_F_* so
> > > the filesystem can notify iomap the extent is in a different device? I don't
> > > know, just a thought.
> > >
> > > This would still keep the consistency of leaving bmap_fiemap() with the decision
> > > of passing or not.
> >
> > I think this actually is a problem with FIEMAP as well, as it
> > doesn't report that things are on a different device. So I guess for
> > now we should fail FIEMAP on the RT device as well.
>
> Or enhance FIEMAP to report some kind of device id like I suggested a
> while back...
Yes, this is in my todo list Darrick, but as agreed previously, this will be in
a different patchset. It simply does not belong here and will make this patchset
much more complex than it should be.
About this patch itself, there isn't much I can do here, and I think a XFS fix
to make it reject FIEMAP for RT devices as Christoph suggested, belongs to a
xfs-only patch, not to this one.
I can do that too, but on a different patch, changing FS semantics simply does
not belong in this patchset.
Cheers.
>
> --D
--
Carlos
next prev parent reply other threads:[~2019-09-23 8:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
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-09-11 13:43 ` [PATCH 2/9] cachefiles: drop direct usage of ->bmap method Carlos Maiolino
2019-09-11 13:43 ` [PATCH 3/9] ecryptfs: drop direct calls to ->bmap Carlos Maiolino
2019-09-11 13:43 ` [PATCH 4/9] fibmap: Use bmap instead of ->bmap method in ioctl_fibmap Carlos Maiolino
2019-09-11 13:43 ` [PATCH 5/9] fs: Move start and length fiemap fields into fiemap_extent_info Carlos Maiolino
2019-09-16 17:42 ` Darrick J. Wong
2019-09-11 13:43 ` [PATCH 6/9] iomap: Remove length and start fields from iomap_fiemap Carlos Maiolino
2019-09-11 13:43 ` [PATCH 7/9] fiemap: Use a callback to fill fiemap extents Carlos Maiolino
2019-09-11 13:43 ` [PATCH 8/9] Use FIEMAP for FIBMAP calls Carlos Maiolino
2019-09-16 17:44 ` Darrick J. Wong
2019-09-11 13:43 ` [PATCH 9/9] xfs: Get rid of ->bmap Carlos Maiolino
2019-09-16 17:50 ` Darrick J. Wong
2019-09-18 8:13 ` Carlos Maiolino
2019-09-18 13:24 ` Christoph Hellwig
2019-09-18 16:12 ` Darrick J. Wong
2019-09-23 8:52 ` Carlos Maiolino [this message]
2019-09-27 8:59 ` [PATCH 0/9 V6] New ->fiemap infrastructure and ->bmap removal Carlos Maiolino
2019-09-30 8:10 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2019-08-08 8:27 [PATCH 0/9 V5] " Carlos Maiolino
2019-08-08 8:27 ` [PATCH 9/9] xfs: Get rid of ->bmap 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 9/9] xfs: Get rid of ->bmap Carlos Maiolino
2019-07-31 23:30 ` 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=20190923085248.ttf6ruum7dp3qqjd@pegasus.maiolino.io \
--to=cmaiolino@redhat.com \
--cc=adilger@dilger.ca \
--cc=darrick.wong@oracle.com \
--cc=hch@lst.de \
--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).