lkml.org 
[lkml]   [2010]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: EXT3 File System Corruption 2.6.34
Date

On Jun 7, 2010, at 6:55 PM, Jeffrey Merkey <jeffmerkey@gmail.com> wrote:

> ---------- Forwarded message ----------
> From: Jeffrey Merkey <jeffmerkey@gmail.com>
> Date: Mon, Jun 7, 2010 at 5:54 PM
> Subject: Re: EXT3 File System Corruption 2.6.34
> To: Eric Sandeen <sandeen@sandeen.net>
>
>
> REPLY TO ALL
>
> CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>
> Whether set this way or not, should not see corruption.

Here you are mistaken. Mount with data=ordered and see. Writeback
can expose stale data.

-Eric

> I am seeing
> data corruption including the following:
>
> /boot/grub/grub.conf getting filled with binary chars
> /root/.viminfo filled with strange text chars (not binary)
> .o files filled with the same garbage.
>
> Looks like EXT3 meta data -- maybe some blocks getting transposed
> somewhere?
>
> I will recreate the data patterns I see during corruption and post
> here. They are consitent with some sort of fill pattern -- at least
> what I see in
> viminfo is.
>
> In the case of corrupted .o files, the endian headers are missing and
> trashed in the OBJ section headers -- chances are the same kind of
> garbage.
>
> Jeff
>
>
>>> Still seeing file system corruption after journal recovery in EXT3.
>>> It's easy to reproduce, though the symptoms vary. One way is to
>>> rebuild a program and while the program is being compiled just shut
>>> off power to the system by pulling the plug. I am seeing the
>>> /root/.viminfo file trashed after recovery if Vim was active during
>>> poweroff. I am also seeing object modules getting built which the
>>> LD
>>> linker claims are "invalid" following a recovery event. I suspect a
>>> bug in the buffer cache since deleting the file still causes the old
>>> data to be returned from buffer cache even when the sectors are
>>> overwritten, but both are interrelated. Seems in some way related
>>> to
>>> EXT3 recovery which results in the buffer cache returning old
>>> sectors
>>> and junk.
>>>
>>> Not hard to reproduce, but the symptoms are always a little
>>> different
>>> but the /root/.viminfo file getting nuked seems a common affect of
>>> this bug.
>>
>> "file system corruption" usually means corrupted metadata, but I
>> guess
>> here you mean file corruption, i.e. corrupted data.
>>
>> If you have buffered data in the cache, it will be lost when you pull
>> the plug. If your userspace doesn't sync it, this is expected.
>> But it's
>> not clear to me what you're seeing.
>>
>> I'm also not clear on what you mean about deleting the file and
>> having old
>> data returned. Maybe a little cut and paste from the screen would
>> help
>> explain what you see.
>>
>> I'd also check CONFIG_EXT3_DEFAULTS_TO_ORDERED and be sure you're
>> using data=ordered mode by default.
>>
>> -Eric
>>
>>> Jeff
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


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