All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@dilger.ca>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Eric Sandeen <sandeen@redhat.com>,
	hch@lst.de, david@fromorbit.com, darrick.wong@oracle.com
Subject: Re: [PATCH 18/20] Use FIEMAP for FIBMAP calls
Date: Mon, 5 Nov 2018 15:15:58 -0700	[thread overview]
Message-ID: <87C8F7EE-519A-4C36-A56C-D9B5E9814D8C@dilger.ca> (raw)
In-Reply-To: <20181030131823.29040-19-cmaiolino@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4086 bytes --]

On Oct 30, 2018, at 7:18 AM, Carlos Maiolino <cmaiolino@redhat.com> wrote:
> 
> Enables the usage of FIEMAP ioctl infrastructure to handle FIBMAP calls,
> from this point, ->bmap() methods can start to be removed.
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
> 
> This patch can be improved, since fiemap_fill_kernel_extent and
> fiemap_fill_usr_extent shares a lot of common code, which still is WIP.
> 
> fs/inode.c         | 35 ++++++++++++++++++++++++++++++-----
> fs/ioctl.c         | 31 +++++++++++++++++++++++++++++++
> include/linux/fs.h |  2 ++
> 3 files changed, 63 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index d09a6f4f0335..389c2165959c 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1591,11 +1591,36 @@ EXPORT_SYMBOL(iput);
>  */
> int bmap(struct inode *inode, sector_t *block)
> {
> -	if (!inode->i_mapping->a_ops->bmap)
> -		return -EINVAL;
> -
> -	*block = inode->i_mapping->a_ops->bmap(inode->i_mapping, *block);
> -	return 0;
> +	struct fiemap_ctx f_ctx;
> +	struct fiemap_extent fextent;
> +	u64 start = *block << inode->i_blkbits;
> +	int error = -EINVAL;
> +
> +	if (inode->i_op->fiemap) {
> +		fextent.fe_logical = 0;
> +		fextent.fe_physical = 0;
> +		f_ctx.fc_extents_max = 1;
> +		f_ctx.fc_extents_mapped = 0;
> +		f_ctx.fc_data = &fextent;
> +		f_ctx.fc_start = start;
> +		f_ctx.fc_len = 1;

Should this be "fc_len = 1 << inode->i_blkbits" to map a single block?
On the one hand, this might return multiple blocks, but on the other
hand FIBMAP shouldn't be allowed if that is the case so this code should
detect that situation and consider it an error.

Cheers, Andreas

> +		f_ctx.fc_flags = 0;
> +		f_ctx.fc_cb = fiemap_fill_kernel_extent;
> +
> +		error = inode->i_op->fiemap(inode, &f_ctx);
> +
> +		if (error)
> +			goto out;
> +
> +		*block = (fextent.fe_physical +
> +			(start - fextent.fe_logical)) >> inode->i_blkbits;
> +
> +	} else if (inode->i_mapping->a_ops->bmap) {
> +		*block = inode->i_mapping->a_ops->bmap(inode->i_mapping, *block);
> +		error = 0;
> +	}
> +out:
> +	return error;
> }
> EXPORT_SYMBOL(bmap);
> 
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 71d11201a06b..dce710699b82 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -113,6 +113,37 @@ int fiemap_fill_usr_extent(struct fiemap_ctx *f_ctx, u64 logical,
> 	return (flags & FIEMAP_EXTENT_LAST) ? 1 : 0;
> }
> 
> +int fiemap_fill_kernel_extent(struct fiemap_ctx *f_ctx, u64 logical,
> +			      u64 phys, u64 len, u32 flags)
> +{
> +	struct fiemap_extent *extent = f_ctx->fc_data;
> +
> +	if (f_ctx->fc_extents_max == 0) {
> +		f_ctx->fc_extents_mapped++;
> +		return (flags & FIEMAP_EXTENT_LAST) ? 1 : 0;
> +	}
> +
> +	if (f_ctx->fc_extents_mapped >= f_ctx->fc_extents_max)
> +		return 1;
> +
> +	if (flags & SET_UNKNOWN_FLAGS)
> +		flags |= FIEMAP_EXTENT_UNKNOWN;
> +	if (flags & SET_NO_UNMOUNTED_IO_FLAGS)
> +		flags |= FIEMAP_EXTENT_ENCODED;
> +	if (flags & SET_NOT_ALIGNED_FLAGS)
> +		flags |= FIEMAP_EXTENT_NOT_ALIGNED;
> +
> +	extent->fe_logical = logical;
> +	extent->fe_physical = phys;
> +	extent->fe_length = len;
> +	extent->fe_flags = flags;
> +
> +	f_ctx->fc_extents_mapped++;
> +
> +	if (f_ctx->fc_extents_mapped == f_ctx->fc_extents_max)
> +		return 1;
> +	return (flags & FIEMAP_EXTENT_LAST) ? 1 : 0;
> +}
> /**
>  * fiemap_fill_next_extent - Fiemap helper function
>  * @fieinfo:	Fiemap context passed into ->fiemap
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 4c6dee908a38..7f623a434cb0 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1704,6 +1704,8 @@ struct fiemap_ctx {
> 	u64 fc_len;
> };
> 
> +int fiemap_fill_kernel_extent(struct fiemap_ctx *f_ctx, u64 logical,
> +			      u64 phys, u64 len, u32 flags);
> int fiemap_fill_next_extent(struct fiemap_ctx *f_ctx, u64 logical,
> 			    u64 phys, u64 len, u32 flags);
> int fiemap_check_flags(struct fiemap_ctx *f_ctx, u32 fs_flags);
> --
> 2.17.1
> 


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

  reply	other threads:[~2018-11-06  7:40 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-30 13:18 [PATCH 00/20] New ->fiemap infrastructure and ->bmap removal Carlos Maiolino
2018-10-30 13:18 ` [PATCH 01/20] fs: Enable bmap() function to properly return errors Carlos Maiolino
2018-10-30 13:18 ` [PATCH 02/20] cachefiles: drop direct usage of ->bmap method Carlos Maiolino
2018-10-30 13:18 ` [PATCH 03/20] ecryptfs: drop direct calls to ->bmap Carlos Maiolino
2018-11-16 15:40   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 04/20] iomap: Rename fiemap_ctx to fiemap_iomap_ctx Carlos Maiolino
2018-11-16 15:44   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 05/20] fs: Introduce fiemap_ctx data structure Carlos Maiolino
2018-11-16 15:46   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 06/20] iomap: Update iomap_fiemap to use new fiemap_ctx structure Carlos Maiolino
2018-11-16 15:48   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 07/20] fiemap: Move fiemap flags to fiemap_ctx Carlos Maiolino
2018-11-05 22:12   ` Andreas Dilger
2018-11-06  8:37     ` Carlos Maiolino
2018-11-16 15:50       ` Christoph Hellwig
2018-11-16 15:51   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 08/20] ext4: Remove direct usage of fiemap_extent_info Carlos Maiolino
2018-11-05 22:13   ` Andreas Dilger
2018-11-06  8:49     ` Carlos Maiolino
2018-10-30 13:18 ` [PATCH 09/20] f2fs: " Carlos Maiolino
2018-10-31  6:10   ` Chao Yu
2018-10-30 13:18 ` [PATCH 10/20] Btrfs: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 11/20] nilfs2: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 12/20] ocfs2: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 13/20] iomap: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 14/20] fiemap: Use fiemap_ctx as fiemap_fill_next_extent argument Carlos Maiolino
2018-11-16 15:54   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 15/20] fiemap: Start using new callback from fiemap_ctx Carlos Maiolino
2018-11-05 22:14   ` Andreas Dilger
2018-11-06  8:52     ` Carlos Maiolino
2018-11-16 15:55       ` Christoph Hellwig
2018-11-19 12:26         ` Carlos Maiolino
2018-11-16 15:57   ` Christoph Hellwig
2018-11-19 12:37     ` Carlos Maiolino
2018-10-30 13:18 ` [PATCH 16/20] fibmap: Use bmap instead of ->bmap method in ioctl_fibmap Carlos Maiolino
2018-11-16 15:58   ` Christoph Hellwig
2018-11-19 12:41     ` Carlos Maiolino
2018-10-30 13:18 ` [PATCH 17/20] fiemap: Get rid of fiemap_extent_info Carlos Maiolino
2018-11-05 22:14   ` Andreas Dilger
2018-11-06  8:56     ` Carlos Maiolino
2018-11-16 16:04   ` Christoph Hellwig
2018-11-19 12:47     ` Carlos Maiolino
2018-10-30 13:18 ` [PATCH 18/20] Use FIEMAP for FIBMAP calls Carlos Maiolino
2018-11-05 22:15   ` Andreas Dilger [this message]
2018-11-06  9:11     ` Carlos Maiolino
2018-11-16 16:06   ` Christoph Hellwig
2018-11-19 12:50     ` Carlos Maiolino
2018-11-20  8:53       ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 19/20] xfs: Get rid of ->bmap Carlos Maiolino
2018-10-30 13:18 ` [PATCH 20/20] ext4: Get rid of ->bmap interface Carlos Maiolino
2018-11-16 16:07   ` 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=87C8F7EE-519A-4C36-A56C-D9B5E9814D8C@dilger.ca \
    --to=adilger@dilger.ca \
    --cc=cmaiolino@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@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 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.