[Bug 453579] Re: in-place corruption of large files *without fsck or reboot* reported with linux 2.6.31-14.46 on ext4

[Andrew M.]

I think I actually *have* seen this...

My setup:
Fileserver, 1.5TB array on JFS bunch of big files (videos mostly, some ISO's and the like - but none of these files *ever* change)
one client with 400GB internal SATA HDD on ext4, running Karmic with 2.6.31-15-generic AMD64 kernel
one client with 1.5TB external USB HDD on ext4, running Karmic with 2.6.31-15-generic i386 kernel

I invoke rsync from the clients as
rsync -axvc root at server:/home/some/dir /home/backup-dir

on *both* clients,  i had to run rsync about 3 times until i no longer
saw changes.

that is to say that there existed differences in the files even during
2nd rsync, which simply shouldn't be.

Also worth noting that another Karmic machine with ext3 and a ppc kernel
doesn't see this problem. Ran rsync once, and then the second pass
didn't change any files.


There doesn't seem to be any rhyme or reason to what files were corrupt or wrong on the clients after the first sync, they weren't the same between the two clients and there didn't seem to be any correlation between increased size and frequency or anything. The "giantest" files (8 GB's or so) transferred correctly the first time.

I've still got this elaborate test set up in place, and I'm *very*VERY*
keen to get this worked out so that I can move to Karmic on the server
(no way in hell I'm upgrading until this gets sorted out!!!)

Please let me know if any more specific tests would help or anything.

-- 
in-place corruption of large files *without fsck or reboot* reported with linux 2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to Linux.