Bug#785189: sendfile stream data corruption

2015-06-29 Thread Fabio Fantoni

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-tools3.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.


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#785189: sendfile stream data corruption

2015-05-13 Thread Ben Hutchings
On Wed, 2015-05-13 at 10:56 +0200, Eduard Bloch wrote:
 Package: linux-source-3.16
 Severity: normal
 
 Hi,
 
 I am not sure how CKT handles bugfix requests but here is something
 which is IMHO worth being backported (it actually applies cleanly to
 3.16). That problem might explain some of those issues:
 https://duckduckgo.com/?q=apt-cacher-ng+hashsum

Those are probably due to mirrors updating files in the wrong order, or
use of multiple inconsistent mirrors via round-robin DNS.

 From current linux git, master branch:
 
 commit 0ff28d9f4674d781e492bcff6f32f0fe48cf0fed
 Author: Christophe Leroy christophe.le...@c-s.fr
 Date:   Wed May 6 17:26:47 2015 +0200
 
 splice: sendfile() at once fails for big files
[...]

This seems to specifically affect use of sendfile with AF_ALG sockets,
not regular network sockets, so it probably doesn't explain that bug.
Nevertheless this is a grave bug.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


signature.asc
Description: This is a digitally signed message part