All of lore.kernel.org
 help / color / mirror / Atom feed
From: "jeff.liu" <jeff.liu@oracle.com>
To: Tao Ma <tao.ma@oracle.com>
Cc: linux-btrfs@vger.kernel.org, sunil.mushran@oracle.com,
	Chris Mason <chris.mason@oracle.com>
Subject: Re: [RFC] btrfs: Don't return extent in fiemap if we meet with a hole.
Date: Thu, 22 Apr 2010 15:13:55 +0800	[thread overview]
Message-ID: <4BCFF733.9030901@oracle.com> (raw)
In-Reply-To: <1271914590-7743-1-git-send-email-tao.ma@oracle.com>

Tao Ma wrote:
> Recently, my colleague Jeff tried to add fiemap support to cp(1).
> http://www.mail-archive.com/bug-coreutils@gnu.org/msg19987.html
> 
> He just meet with a strange issue with following command:
> dd if=/dev/null of=/btrfs/sparse bs=1 seek=4096
> When we use fiemap to the file, btrfs returns an extent with len '4096'
> and flag 'unwritten' while actually there is no data allocated.
> 
> I just dived into this and to my surprise, it is done by btrfs
> intentionally. I checked other file systems which support fiemap.
> Actually with the file created by the script, ocfs2, ext3/4 and
> xfs all return zero extent. And according to the documentation file
> Documentation/filesystems/fiemap.txt, FIEMAP_EXTENT_UNWRITTEN should
> be used when the extent is allocated but it's data has not been
> initialized. So I think btrfs should work like other filesystems.
> 
> Cc: Jeff Liu <jeff.liu@oracle.com>
> Cc: Chris Mason <chris.mason@oracle.com>
> Signed-off-by: Tao Ma <tao.ma@oracle.com>
> ---
>  fs/btrfs/extent_io.c |   15 +++++++++------
>  1 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index b177ed3..7eb4d77 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -2951,7 +2951,7 @@ int extent_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>  	u32 flags = 0;
>  	u64 disko = 0;
>  	struct extent_map *em = NULL;
> -	int end = 0;
> +	int end = 0, hole = 0;
>  	u64 em_start = 0, em_len = 0;
>  	unsigned long emflags;
>  	ret = 0;
> @@ -2978,12 +2978,13 @@ int extent_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>  
>  		disko = 0;
>  		flags = 0;
> +		hole = 0;
>  
>  		if (em->block_start == EXTENT_MAP_LAST_BYTE) {
>  			end = 1;
>  			flags |= FIEMAP_EXTENT_LAST;
>  		} else if (em->block_start == EXTENT_MAP_HOLE) {
> -			flags |= FIEMAP_EXTENT_UNWRITTEN;
> +			hole = 1;
>  		} else if (em->block_start == EXTENT_MAP_INLINE) {
>  			flags |= (FIEMAP_EXTENT_DATA_INLINE |
>  				  FIEMAP_EXTENT_NOT_ALIGNED);
> @@ -3015,10 +3016,12 @@ int extent_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>  			end = 1;
>  		}
>  
> -		ret = fiemap_fill_next_extent(fieinfo, em_start, disko,
> -					em_len, flags);
> -		if (ret)
> -			goto out_free;
> +		if (!hole) {
> +			ret = fiemap_fill_next_extent(fieinfo, em_start, disko,
> +						      em_len, flags);
> +			if (ret)
> +				goto out_free;
> +		}
>  	}
>  out_free:
>  	free_extent_map(em);

I have just tried a simple test against this patch, it works for me.


Thanks,
-Jeff

      reply	other threads:[~2010-04-22  7:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22  5:36 [RFC] btrfs: Don't return extent in fiemap if we meet with a hole Tao Ma
2010-04-22  7:13 ` jeff.liu [this message]

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=4BCFF733.9030901@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sunil.mushran@oracle.com \
    --cc=tao.ma@oracle.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.