* [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole.
@ 2010-06-21 6:37 Tao Ma
2010-06-21 7:36 ` jeff.liu
2010-06-22 0:56 ` Chris Mason
0 siblings, 2 replies; 4+ messages in thread
From: Tao Ma @ 2010-06-21 6:37 UTC (permalink / raw)
To: linux-btrfs; +Cc: linux-kernel, Tao Ma, Chris Mason
Hi Chris,
could you please consider merging this patch? It should be
trivial enough. It helps Jeff adding fiemap support to cp.
Regards,
Tao
>From 909effe7240be30dbc9403dd8cbb326587c3cc02 Mon Sep 17 00:00:00 2001
From: Tao Ma <tao.ma@oracle.com>
Date: Thu, 22 Apr 2010 12:38:57 +0800
Subject: [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole.
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: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Tested-by: Jeff Liu <jeff.liu@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,
u64 disko = 0;
struct extent_map *em = NULL;
struct extent_state *cached_state = 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);
--
1.6.3.3.334.g916e1.dirty
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole.
2010-06-21 6:37 [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole Tao Ma
@ 2010-06-21 7:36 ` jeff.liu
2010-06-22 0:57 ` Chris Mason
2010-06-22 0:56 ` Chris Mason
1 sibling, 1 reply; 4+ messages in thread
From: jeff.liu @ 2010-06-21 7:36 UTC (permalink / raw)
To: Chris Mason, Tao Ma; +Cc: linux-btrfs, linux-kernel
Hi Chris,
Could you please also consider another tiny patch below combine with Tao's?
It fix extent flags to FIEMAP_FLAG_UNWRITTEN if it was fallocate(2) and its "em->block_start ==
EXTENT_MAP_LAST_BYTE".
>From 63904ff528842bcbe20e9d34763c5e689c2f7ace Mon Sep 17 00:00:00 2001
From: Jeff Liu <jeff.liu@oracle.com>
Date: Mon, 21 Jun 2010 15:28:36 +0800
Subject: [PATCH] Fix fiemap extent flag to FIEMAP_FLAG_UNWRITTEN if it is fallocated.
Signed-off-by: Jeff Liu <jeff.liu@oracle.com>
---
fs/btrfs/extent_io.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index a4080c2..e68fd61 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3005,6 +3005,8 @@ int extent_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
}
if (test_bit(EXTENT_FLAG_COMPRESSED, &em->flags))
flags |= FIEMAP_EXTENT_ENCODED;
+ if (test_bit(EXTENT_FLAG_PREALLOC, &em->flags))
+ flags |= FIEMAP_EXTENT_UNWRITTEN;
emflags = em->flags;
free_extent_map(em);
--
1.7.1
Thanks,
-Jeff
Tao Ma wrote:
> Hi Chris,
> could you please consider merging this patch? It should be
> trivial enough. It helps Jeff adding fiemap support to cp.
>
> Regards,
> Tao
>
> From 909effe7240be30dbc9403dd8cbb326587c3cc02 Mon Sep 17 00:00:00 2001
> From: Tao Ma <tao.ma@oracle.com>
> Date: Thu, 22 Apr 2010 12:38:57 +0800
> Subject: [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole.
>
> 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: Chris Mason <chris.mason@oracle.com>
> Signed-off-by: Tao Ma <tao.ma@oracle.com>
> Tested-by: Jeff Liu <jeff.liu@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,
> u64 disko = 0;
> struct extent_map *em = NULL;
> struct extent_state *cached_state = 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);
--
With Windows 7, Microsoft is asserting legal control over your computer and is using this power to
abuse computer users.
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole.
2010-06-21 6:37 [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole Tao Ma
2010-06-21 7:36 ` jeff.liu
@ 2010-06-22 0:56 ` Chris Mason
1 sibling, 0 replies; 4+ messages in thread
From: Chris Mason @ 2010-06-22 0:56 UTC (permalink / raw)
To: Tao Ma; +Cc: linux-btrfs, linux-kernel
On Mon, Jun 21, 2010 at 02:37:02PM +0800, Tao Ma wrote:
> Hi Chris,
> could you please consider merging this patch? It should be
> trivial enough. It helps Jeff adding fiemap support to cp.
Yes, I'll add this in, thanks!
-chris
>
> Regards,
> Tao
>
> From 909effe7240be30dbc9403dd8cbb326587c3cc02 Mon Sep 17 00:00:00 2001
> From: Tao Ma <tao.ma@oracle.com>
> Date: Thu, 22 Apr 2010 12:38:57 +0800
> Subject: [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole.
>
> 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: Chris Mason <chris.mason@oracle.com>
> Signed-off-by: Tao Ma <tao.ma@oracle.com>
> Tested-by: Jeff Liu <jeff.liu@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,
> u64 disko = 0;
> struct extent_map *em = NULL;
> struct extent_state *cached_state = 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);
> --
> 1.6.3.3.334.g916e1.dirty
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole.
2010-06-21 7:36 ` jeff.liu
@ 2010-06-22 0:57 ` Chris Mason
0 siblings, 0 replies; 4+ messages in thread
From: Chris Mason @ 2010-06-22 0:57 UTC (permalink / raw)
To: jeff.liu; +Cc: Tao Ma, linux-btrfs, linux-kernel
On Mon, Jun 21, 2010 at 03:36:29PM +0800, jeff.liu wrote:
> Hi Chris,
>
> Could you please also consider another tiny patch below combine with Tao's?
> It fix extent flags to FIEMAP_FLAG_UNWRITTEN if it was fallocate(2) and its "em->block_start ==
> EXTENT_MAP_LAST_BYTE".
Thanks, will do.
-chris
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-06-22 0:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-21 6:37 [PATCH RESEND] btrfs: Don't return extent in fiemap if we meet with a hole Tao Ma
2010-06-21 7:36 ` jeff.liu
2010-06-22 0:57 ` Chris Mason
2010-06-22 0:56 ` Chris Mason
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).