[ 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
