Date:	Tue, 22 Feb 2011 16:18:53 -0500
From:	Chris Mason <chris.mason@...cle.com>
To:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: fiemap bugs on sparse files.

[ resend, sorry if this is a dup ]

Hi everyone,

We've had reports on btrfs that cp is giving us files full of zeros
instead of actually copying them.  It was tracked down to a bug with
the btrfs fiemap implementation where it was returning holes for
delalloc ranges.

Newer versions of cp are trusting fiemap to tell it where the holes
are, which does seem like a pretty neat trick.

I decided to give xfs and ext4 a shot with a few tests cases too, xfs
passed with all the ones btrfs was getting wrong, and ext4 got the basic
delalloc case right.

# mkfs.ext4 /dev/xxx
# mount /dev/xxx /mnt
# dd if=/dev/zero of=/mnt/foo bs=1M count=1
# fiemap-test foo
ext:   0 logical: [       0..     255] phys:        0..     255 flags: 0x007 tot: 256

Horray!  But once we throw a hole in, things go bad:

# mkfs.ext4 /dev/xxx
# mount /dev/xxx /mnt
# dd if=/dev/zero of=/mnt/foo bs=1M count=1 seek=1
# fiemap-test foo
< no output >

We've got a delalloc extent after the hole and ext4 fiemap didn't find
it.  If I run sync to kick the delalloc out:

# sync
# fiemap-test foo
ext:   0 logical: [     256..     511] phys:    34048..   34303 flags: 0x001 tot: 256

fiemap-test is sitting in my /usr/local/bin, and I have no idea how it
got there.  It's full of pretty comments so I know it isn't mine, but
you can grab it here:

http://oss.oracle.com/~mason/fiemap-test.c

xfsqa has a fiemap program too.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists