linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, sandeen@redhat.com, hch@lst.de,
	david@fromorbit.com, darrick.wong@oracle.com
Subject: Re: [PATCH 17/20] fiemap: Get rid of fiemap_extent_info
Date: Fri, 16 Nov 2018 17:04:02 +0100	[thread overview]
Message-ID: <20181116160402.GA17130@lst.de> (raw)
In-Reply-To: <20181030131823.29040-18-cmaiolino@redhat.com>

On Tue, Oct 30, 2018 at 02:18:20PM +0100, Carlos Maiolino wrote:
> With the goal of using FIEMAP infra-structure for FIBMAP ioctl, and with
> the updates being done previously into the FIEMAP interface, the
> fiemap_extent_info structure is no longer necessary, so, move
> fi_extents_mapped and fi_extents_max up to fiemap_ctx. and use
> fiemap_ctx.fc_data to hold a pointer to struct fiemap_extent.
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
>  fs/btrfs/extent_io.c  |  3 +--
>  fs/ioctl.c            | 29 +++++++++++++----------------
>  include/linux/fs.h    |  9 ++-------
>  include/linux/iomap.h |  1 -
>  4 files changed, 16 insertions(+), 26 deletions(-)
> 
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index 6a8bc502bc04..88b8a4416dfc 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -4436,7 +4436,6 @@ int extent_fiemap(struct inode *inode, struct fiemap_ctx *f_ctx)
>  	struct btrfs_path *path;
>  	struct btrfs_root *root = BTRFS_I(inode)->root;
>  	struct fiemap_cache cache = { 0 };
> -	struct fiemap_extent_info *fieinfo = f_ctx->fc_data;
>  	int end = 0;
>  	u64 em_start = 0;
>  	u64 em_len = 0;
> @@ -4561,7 +4560,7 @@ int extent_fiemap(struct inode *inode, struct fiemap_ctx *f_ctx)
>  		} else if (em->block_start == EXTENT_MAP_DELALLOC) {
>  			flags |= (FIEMAP_EXTENT_DELALLOC |
>  				  FIEMAP_EXTENT_UNKNOWN);
> -		} else if (fieinfo->fi_extents_max) {
> +		} else if (f_ctx->fc_extents_max) {
>  			u64 bytenr = em->block_start -
>  				(em->start - em->orig_start);

Shouldn't this be earlier, when or just after when we introduce 
f_ctx->fc_extents_max?

>  		return (flags & FIEMAP_EXTENT_LAST) ? 1 : 0;

Can you use a plain old if statment here to make the code a little
more readable?

		if (flags & FIEMAP_EXTENT_LAST)
			return 1;
		return 0;

>  struct fiemap_ctx {
>  	unsigned int fc_flags;	/* Flags as passed from user */
> +	unsigned int fc_extents_mapped;	/* Number of mapped extents */
> +	unsigned int fc_extents_max;	/* Size of fiemap_extent array */
>  	void *fc_data;
>  	fiemap_fill_cb fc_cb;
>  	u64 fc_start;

This makes me wonder if we shouldn't just have kept the existing
structure and massaged it into the new form.  The two just look
very, very similar..

  parent reply	other threads:[~2018-11-17  2:17 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 [this message]
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
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=20181116160402.GA17130@lst.de \
    --to=hch@lst.de \
    --cc=cmaiolino@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --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 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).