Re: [PATCH 8/9] Use FIEMAP for FIBMAP calls

From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@lst.de>,
	linux-fsdevel@vger.kernel.org, adilger@dilger.ca,
	jaegeuk@kernel.org, miklos@szeredi.hu, rpeterso@redhat.com,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 8/9] Use FIEMAP for FIBMAP calls
Date: Mon, 16 Sep 2019 08:58:48 -0700	[thread overview]
Message-ID: <20190916155848.GW2229799@magnolia> (raw)
In-Reply-To: <20190910122833.jsii3us7rhwc5l2p@pegasus.maiolino.io>

On Tue, Sep 10, 2019 at 02:28:35PM +0200, Carlos Maiolino wrote:
> Hey, thanks for the info.
> 
> Although..
> 
> On Thu, Aug 29, 2019 at 09:15:55AM +0200, Christoph Hellwig wrote:
> > 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.
> 
> This seems doable, yes, but... Doing that essentially will make some
> filesystems, like BTRFS, to suddenly start to support fibmap, this was another
> reason why we opted in the first place to let filesystems know whom the caller
> was.
> 
> We could maybe add a new FIEMAP_EXTENT_* flag in the future to, let's say,
> specify a specific block may be split between more than one device, but, well.
> It's an idea, but it won't change the fact BTRFS for example will suddenly start
> to support FIBMAP.

...or burn another superblock sb_flag on "this fs supports FIBMAP";
have the in-kernel bmap() function bail out if it isn't set; and only
set it for the filesystems that used to supply ->bmap?

--D

> -- 
> Carlos