Possible bug in mkfs.ext3

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.

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 <[email protected]> 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