[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#501134: RAW-pictures break down after copied on a crypted raid5



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 <ben@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
 

Reply to: