Bug#785189: sendfile stream data corruption
I also have a problem probably related to this, but I'm not sure.
On one of my systems with wheezy and btrfs-tools and kernel from
backports I have file corruption copying a big sparse file from a btrfs
filesystem (to btrfs or to ext4) with cp --sparse=never. Source and
destination don't compare equal with the cmp command (the destination
appear zeroed in places where it shouldn't be). Copying the same file
with "cat file > filenew" they compare equal, as well as omitting the
--sparse option to cp. I never experienced the problem copying from ext4
as source.
linux-image-3.16.0-0.bpo.4-amd64 3.16.7-ckt11-1~bpo70+1
btrfs-tools 3.17-1.1~bpo70+1
I tried with many files with the same result, I already did extended
selftest of the harddisk and fsck without finding errors.
I have the same problem also on an old test installation with kernel
3.14 (old backport), so it doesn't seem a recent regression.
The system is running xen and I'm making copies on the dom0. The files
I'm copying are dumUs disks (of course they are turned off while I'm
making the copy and comparing them). Problematic files are part of
different btrfs snapshots or reflink but they are not corrupted as long
as you do simple read/write on them.
This seems a very important bug that may corrupt important files for
some btrfs users.
If you need more informations/tests tell me and I'll post them.
Thanks for any reply.
Reply to: