Soliciting contractor for FS corruption analysis [was: Re: Second Block on Partition overwritten with 0xFF]

[Tomas Pospisek ML]

(this is a repost with the subject and slight text corrections)

Hello Ext3 world,

my customer is still experiencing a too high percentage of machine
outages with corrupted superblocks - roughly 10% of our embedded PC
population.

Thus we are looking to contract an expert to resolve our FS problem.

The details of our problem should be roughly sketched in the previous
thread (please look in the ML archives for the thread "Second Block on
Partition overwritten with 0xFF").

We can provide images (as in dd if=/dev/hdx of=disk_image) of the
corrupted file systems. We are also ready to organize travel to our site
(Switzerland) if necessary and/or live access to our units.

Also any pointers to experts on the subject of ext2/3, IDE, flash cards
are highly appreciated.

Once again, any and all pointers to sources of help for our problem are
very, very appreciated, please do contact us! Thanks in advance,
*t

On 9/9/2007, "Tomas Pospisek's Mailing Lists" <tpo2 at sourcepole.ch>
wrote:

>On Thu, 6 Sep 2007, Andreas Dilger wrote:
>
>> On Sep 06, 2007  23:02 +0200, Tomas Pospisek's Mailing Lists wrote:
>>> On Thu, 6 Sep 2007, Christian Kujau wrote:
>>>> On Thu, 6 Sep 2007, Tomas Pospisek ML wrote:
>>>>> default) at 0x400. Thus as I understand it, it *would* be possible for
>>>>> the ext3 driver to pysically write to those first sectors inside its
>>>>> partition.                                                ^^^^^^
>>>>
>>>> Yes, ext3 will write *inside* its assigned partition, but not outside.
>>>
>>> Thanks, however it seems I can not get through what I need to know -
>>> sorry for that. I *do* know that ext3 will only write to its partition
>>> only. But once mke2fs has run:
>>>
>>> * will ext2/3 *ever* write to the first 4 sectors on *its* partition?
>>>
>>> Same question restated: is it possible that ext2/3 will write into the
>>> space before the first block group [1]?
>>
>> The ext2/3/4 superblock is at offset 1024 bytes.  It is written by marking
>> the buffer it is in dirty.  If the filesystem blocksize is > 1024 bytes
>> then the whole block will be written to disk (including the first sectors).
>>
>> That said, the buffer cache is coherent when written by the filesystem and
>> when written via /dev/XXX so any modifications made to the first sectors
>> should be rewritten each time the superblock is marked dirty.  The ext3
>> code will never itself modify those sectors.
>
>I just remembered, that once the problem occured when there was very high
>memory pressure. I.e. the OOM killer went around and killed applications,
>the machine rebooted, at which point the FS was broken.
>
>So a naive ad hoc theory of mine for the FS corruption would be that the
>FS was unmounted at a moment when processes wouldn't receive any more
>memory from the OS (due to OOM) and thus umount would flush/write out the
>first block (I believe it needs to obligatorily clear the dirty FS flag at
>umount) which it failed to properly allocate before?!?
>*t
>
>--
>-----------------------------------------------------------
>   Tomas Pospisek
>   http://sourcepole.com -  Linux & Open Source Solutions
>-----------------------------------------------------------
>
>_______________________________________________
>Ext3-users mailing list
>Ext3-users at redhat.com
>https://www.redhat.com/mailman/listinfo/ext3-users
>

_______________________________________________
Ext3-users mailing list
Ext3-users at redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users