linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Christoph Hellwig <hch@lst.de>,
	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 8/9] Use FIEMAP for FIBMAP calls
Date: Thu, 29 Aug 2019 09:15:55 +0200	[thread overview]
Message-ID: <20190829071555.GF11909@lst.de> (raw)
In-Reply-To: <20190820130117.gcemlpfrkqlpaaiz@pegasus.maiolino.io>

On Tue, Aug 20, 2019 at 03:01:18PM +0200, Carlos Maiolino wrote:
> On Wed, Aug 14, 2019 at 01:18:37PM +0200, Christoph Hellwig wrote:
> > The whole FIEMAP_KERNEL_FIBMAP thing looks very counter productive.
> > bmap() should be able to make the right decision based on the passed
> > in flags, no need to have a fake FIEMAP flag for that.
> 
> Using the FIEMAP_KERNEL_FIBMAP flag, is a way to tell filesystems from where the
> request came from, so filesystems can handle it differently. For example, we
> can't allow in XFS a FIBMAP request on a COW/RTIME inode, and we use the FIBMAP
> flag in such situations.

But the whole point is that the file system should not have to know
this.  It is not the file systems business in any way to now where the
call came from.  The file system just needs to provide enough information
so that the caller can make informed decisions.

And in this case that means if any of FIEMAP_EXTENT_DELALLOC,
FIEMAP_EXTENT_ENCODED, FIEMAP_EXTENT_DATA_ENCRYPTED,
FIEMAP_EXTENT_NOT_ALIGNED, FIEMAP_EXTENT_DATA_INLINE,
FIEMAP_EXTENT_DATA_TAIL, FIEMAP_EXTENT_UNWRITTEN or
FIEMAP_EXTENT_SHARED is present the caller should fail the
bmap request.

  reply	other threads:[~2019-08-29  7:15 UTC|newest]

Thread overview: 48+ 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
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 [this message]
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 8/9] Use FIEMAP for FIBMAP calls Carlos Maiolino
2019-09-16 17:44   ` Darrick J. Wong
2019-07-31 14:12 [PATCH 0/9 V4] New ->fiemap infrastructure and ->bmap removal Carlos Maiolino
2019-07-31 14:12 ` [PATCH 8/9] Use FIEMAP for FIBMAP calls Carlos Maiolino
2019-07-31 14:12   ` Carlos Maiolino
2019-07-31 23:22   ` Darrick J. Wong
2019-07-31 23:31     ` Darrick J. Wong
2019-08-02 13:52       ` Carlos Maiolino
2019-08-06  5:41       ` Christoph Hellwig
2019-08-02 13:48     ` Carlos Maiolino
2019-08-02 15:29       ` Darrick J. Wong
2019-08-05 10:38         ` Carlos Maiolino
2019-08-06  5:46         ` Christoph Hellwig

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=20190829071555.GF11909@lst.de \
    --to=hch@lst.de \
    --cc=adilger@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --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).