Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Chris Mason <chris.mason <at> oracle.com>
Subject: fiemap bugs on sparse files.
Newsgroups: gmane.comp.file-systems.ext4
Date: Tuesday 22nd February 2011 21:18:53 UTC (over 6 years ago)
[ 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 16ms