lkml.org 
[lkml]   [2010]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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>


\
 
 \ /
  Last update: 2010-06-08 04:09    [W:0.370 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site