The bug seems to be fixed in the current Debian 6.0 'squeeze' with the 2.6.32-5-amd64 kernel. I'm running it on new hardware but with a similar configuration (luks-crypted raid 5) and couldn't reproduce the described problem.
Thanks for answering!! - better late, than never ;-) Daniel 2012/4/23 Ben Hutchings <b...@decadent.org.uk> > On Sat, 2008-10-04 at 17:01 +0200, daniel starzmann wrote: > > Package: linux-image-2.6.24-etchnhalf.1-486 > > Version: ? > > > > > > Hello, > > I have an extra-ordinary problem or perhaps an Kernel bug: > > I'm very sorry that we haven't responded to your bug report. It is > clearly a serious bug, but your report seems to have been missed due to > changes in package names. > > > My Server: > > * Debian Etch (Kernel: Etch-n-half), Samba 3.0.24 > > * 500gb harddisk with a system and a data partition. Both are crypted > > with Luks (cipher:serpent-cbc-essiv:sha256) > > * Raid 5 crypted with Luks (cipher: serpent-cbc-essiv:sha256) > > * All partitions have the ext3 filesystem > > > > Client1: Notebook (Windows XP and Fedora) > > Client2: Desktop (Fedora) > > I did all tests from both clients > > > > My problem: > > I tried to copy RAW pictures (*.cr2 files) from a client to the raid5 > > partition with the following 4 different ways. > > > > 1. I exported the raid partition with samba and copied the pictures with > > Windows XP and the Windows Explorer > > 2. I copied the pictures through an smb-mount with Fedora with the > > "cp"-command > > 3. I copied the pictures with the "scp"-command (first initiiated from > > the client and then from the server) > > 4. I copied the pictures with the "rsync"-command (first initiiated from > > the client and then from the server) > > Thank you for the thorough testing. > > > I checked the files after I had copied them with "md5sum" and I saw that > > the values where different to the values of the original files. > > The pictures where broken. They had lila stribes and where cutted in the > > half. > > I tried the same 4 methods and copied the pictures on the 500gb data > > partition and there where no failures or md5sum differences. > > Then I copied the pictures in an ssh shell with an normal cp-command > > from the local-partition to the raid5-partition. The md5sum values where > > the same, so this worked well. > > It might just be that in this case the files were read back from the > cache (memory) instead of from the disk. > > > So in my opinion the problem has to do with the crypted raid5. > > I tried to reproduce this failures with other files but i had this > > problem only with RAW (*.cr2 Canon) picture files. > > Perhaps related to the size of the files? > > > I tried to repair my system with these 3 Methods: > > 1. fsck.ext3 -y /dev/mapper/md0_crypt > > 2. fsck.ext3 -c -p /dev/mapper/md0_crypt > > 3. server rebooted a few times > > I couldn't find out any failure messages in the log-files or at the > > booting. > > > > > > After many hours I found this out: > > With Kernel 2.6.24-etchnhalf.1-686, Kernel 2.6.24-etchnhalf.1-486 and > > Kernel 2.6.26-bpo.1-486 I could reproduce my Image-copy-problem. > > As I booted the older Kernel 2.6.18-6-486 I where able to copy the > > pictures with any of the methods above and the md5sum values where OK. > > Because of this I think its an Kernel problem. > [...] > > That certainly seems to be the case. Do you know whether a later > version (e.g. Linux 2.6.32 in Debian 6.0 'squeeze') fixed this bug? > > Ben. > > -- > Ben Hutchings > For every action, there is an equal and opposite criticism. - Harrison
