Messages in this thread | | | Date | Mon, 07 Jun 2010 21:05:44 -0500 | From | Eric Sandeen <> | Subject | Re: Fwd: EXT3 File System Corruption 2.6.34 |
| |
Jeffrey Merkey wrote:
> OK. I will set this up. You may want to make this option the default > in the build scripts. here is a corrupted file.
It was default, but Linus changed it a while back.
> This was a .gif > image file I saved THEN AFTER SAVING THE FILE I pulled the power to > the machine and during recovery the file was FUCKED.
I assume your application did not sync the data, and buffered data loss is expected on a power loss.
> At any rate, > this does not happen with 2.6.28.
that I can't explain for sure.... different timing perhaps.
> I dumped the file with xdump a util I use internally for my own use so > you could see the file contents as text and I could post it here. > This was an image file but look what ended up in it -- directory > blocks and such. Take a look:
As I said, stale blocks exposed due to data=writeback. Known behavior, unfortunately the default for ext3. If you find similar problems when mounted data=ordered, it's a more interesting report.
-Eric
> 0 1 2 3 4 5 6 7 8 9 A B C D E F > 00000000 6C 73 0A 63 64 20 2E 2E 0A 63 6C 73 0A 6C 73 0A ls.cd ...cls.ls. > 00000010 63 64 20 6C 69 6E 75 78 2D 32 2E 36 2E 33 34 2D cd linux-2.6.34- > 00000020 6D 64 62 2F 0A 63 6C 73 0A 6C 73 0A 63 64 20 2E mdb/.cls.ls.cd . > 00000030 2E 0A 63 6C 73 0A 6C 73 0A 63 64 20 6C 69 6E 75 ..cls.ls.cd linu
<giant snip>
| |