Possible bug in mkfs.ext3

[Andreas Dilger]

On Sep 19, 2014, at 7:56 PM, jd1008 <jd1008 at gmail.com> wrote:
> I am reporting this on the advice of the Fedora Users Mailing List Member.
> 
> This the mailing list exchange outlining the problem with specifying -S to mkfs, and it's subsequent consequences when fsck is run.
> 
> I am reporting this per suggestions made to me on the Fedora Users Mailing List.

I would say that "mke2fs -S" is going to lead to worse corruption rather
than improving the situation in 999 times of 1000.  It should only be
used by someone who knows very specific details of the filesystem and
how it was corrupted.  I'm tempted to make it an "undocumented" feature,
since I suspect it will do more harm than good in most cases.  "-S"
should at least call check_plausibility() and proceed_question() before
clobbering the filesystem.

Better would be something like the "findsuper" utility in the e2fsprogs
sources (attached here for your conveniece).  Usually in cases like this
the problem is actually something with the partition table, and not that
all of your backup superblocks have mysteriously been corrupted at the
same time.

Cheers, Andreas

> The following is the mailing list exchange:
> 
> 
> On 09/18/2014 07:01 PM, Robert Nichols wrote:
>> On 09/18/2014 12:37 PM, jd1008 wrote:
>>> Is there any other tool that can extract files from a partition that
>>> seems to have corrupted superblocks?
>>> I tried dumpe2fs, and fsck -b <blockNumber>
>>> to no avail. Tried all available block numbers that are listed
>>> when original mkfs was done, and it's output was saved.
>>> 
>>> None of the blocks seem to work - all of them have invalid magic.
>> 
>> Verify that the partition table still appears to be correct.  If it
>> is pointing to the wrong starting location, none of the super blocks
>> will appear in the expected places. You might see if /testdisk/can
>> find any intact super blocks.
>> 
>> Consider using a hex editor to look at some of the super blocks.
>> They should contain the same data.  The data that actually appears
>> there might give some clue as to what happened.
>> 
>> As a last ditch recovery effort, run mke2fs/mke3fs with the "-S"
>> option to initialize the super blocks and group descriptors only.
>> Do this only with (or on) a backup copy of the partition, since
>> it is potentially destructive.  Then see if /debugfs/can make
>> sense of the filesystem, and if so, run /fsck/with the "-f"
>> option to repair the metadata. 
> 
> 
> On 09/19/2014 07:16 PM, Chris Murphy wrote:
>> On Sep 19, 2014, at 11:49 AM, jd1008 <jd1008 at gmail.com> wrote:
>> 
>>> On 09/19/2014 08:39 AM, Robert Nichols wrote:
>>>> On 09/18/2014 10:57 PM, jd1008 wrote:
>>>>> I ran mkfs.ext3 -S  /dev/sdc7
>>>>> then ran fsck.ext3 -y /dev/sdc7
>>>>> it blew away EVERYTHING :)
>>>>> 
>>>>> Back to square one and re-dd original to test drive
>>>>> and start over.
>>>> Ouch!  That _used_ to work.  Trying it just now, "mke3fs -S" seems
>>>> to clear a substantial portion of the inodes, which the manpage
>>>> specifically says it should _not_ do, and then /fsck/ completes the
>>>> destruction by moving all of the remaining inodes to lost+found.
>>>> 
>>>> Sorry about that.
>>>> 
>>> Can raise a bug against it?
>> Chances are this is an upstream bug, or a misunderstanding. You should post your reproduce steps to the ext4 list, what you expect to happen based on man page, and what actually happens.
>> http://vger.kernel.org/vger-lists.html#linux-ext4
>> 
>> 
>> Chris Murphy
> 
> _______________________________________________
> Ext3-users mailing list
> Ext3-users at redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users


Cheers, Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: findsuper.c
Type: application/octet-stream
Size: 8259 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20140920/f98db66b/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20140920/f98db66b/attachment.sig>