Ian! D. Allen (idallen) wrote: "It took many more runs (several dozen) to discover the corruption than when using the 2.6.38 kernel, and *only* the md5sums changed between runs, not the file sizes as well as was true with 2.6.38."
Have you ruled out hardware causes (e.g. tried the same test on a different computer)? I'm asking this because I was just yesterday able to detect a really hard to track hardware issue with my own computer. It was manifesting itself as random sha1sum changes to in files when computing checksums for a 18 GB data set. The system had 8 GB of SDRAM. The memtest86 was not able to detect any problems when I run it for 5 hours but I was always able to reproduce the checksum errors in less than 15 minutes by trying to compute sha1sums repeatedly. In that case, the problem turned to be an incorrectly behaving memory chip. The problem vanished when I stopped using that part! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/509180 Title: ecryptfs sometimes seems to add trailing garbage to encrypted files To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/509180/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
