Re: mounting ext3 with another superblock doesn't work?

Re: mounting ext3 with another superblock doesn't work?

[Amir G.]

Hi Christoph,

First, sending this question to linux-ext4 is your best bet.
Second, I have this email from Mike, who had the exact same problem.
I gave him some advice (off the list for some reason).

So you can do one 2 things:
1. take comfort that you are not alone
2. ask Mike if my advice helped him or if he found other ways to
overcome the problem. I think he used an LVM snapshot to make
some experiments before actually making changing to the fs.

Your situation may be even better off than Mike's.
If you really hit ctrl-C after overwriting only super block and inode block #0,
then you haven't really lost much 'information'
the super block and inode block #0 from a new formatted fs, should contain
roughly the exact same 'information', the only exception is files (not
directories) created
at the root dir. those file inodes information would have been been lost.

Again, if you have a way to make a full backup of your drive,
before doing any experiments, that would be wise...
Also, when you attempt to mount the fs, better try readonly mount.
If there are lost files or your drive, you don't want to overwrite their data.

Good luck,
Amir.

---------- Forwarded message ----------
From: Amir Goldstein <amir73il@gmail.com>
Date: Sun, Dec 19, 2010 at 11:01 PM
Subject: Re: Accidental mkfs.ext4 on wrong volume already formatted with ext4...
To: Mike Swanson <mikeonthecomputer@gmail.com>


On Sat, Dec 18, 2010 at 12:12 PM, Mike Swanson
<mikeonthecomputer@gmail.com> wrote:
> Hey,
>
> In some stupid late night adventures, I accidentally ran mke2fs on my
> normal /home volume (1.3TB, about 600GB used....) rather than a new
> volume I had intended... I quickly realized my mistake and did ^C
> though I'm not sure what my options are now for possible recovery....
>
> # mkfs.ext4 /dev/freedom/home
> mke2fs 1.41.12 (17-May-2010)
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> Stride=0 blocks, Stripe width=0 blocks
> 85196800 inodes, 340787200 blocks
> 17039360 blocks (5.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=0
> 10400 block groups
> 32768 blocks per group, 32768 fragments per group
> 8192 inodes per group
> Superblock backups stored on blocks:
>        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
>        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
>        102400000, 214990848
>
> Writing inode tables: ^C 41/10400
> #
>
> "dumpe2fs -o superblock=20480000" seems to give the old superblock
> metadata still... filesystem create time, last write, etc, though
> running e2fsck results in this:
> # e2fsck -n -b 20480000 /dev/freedom/home
> e2fsck 1.41.12 (17-May-2010)
> Superblock has an invalid journal (inode 8).
> Clear? no
>
> e2fsck: Illegal inode number while checking ext3 journal for /dev/freedom/home
>
>
> I'm in a panic and I don't know what to do.. if anyone can help
> recover data from this accident it would be much appreciated

Oh, what a mess...

I cannot offer you much, but I will try to assess your situation and
offer some tips I would try.
I do not offer fixing tools nor have those tips ever been tested by myself.
I do hope that I am not mumbling nonsense and planting fake hopes...

It appear from the logs, that you have wiped the super block and all
of it's backups
and the first 41 block groups inode tables.

Maybe you have a working copy of your super block and maybe you don't,
but assuming you know the parameters you used to format the partition
in the first place, recovering a sane super block shouldn't be too hard.
I think Fsck can fix the most of the fields later (???)
The real problem is the lost inodes.

What you know for sure is that you have wiped the root inode (2)
resize inode (7), journal inode (8) and every file
which was ever created in the root directory.

So suppose you have the ability to format a file system , which looks the same
as your file system when it was created (using same mkfs parameters and
preferably the same mkfs version), you can use that to copy a sane version
of root, resize, and journal inodes.

The journal inode should be identical to the one you wiped (it never
changes after mkfs).
The resize inode also never changes unless you did online resize, but
it can be fixed by fsck.
The root inode (containing the root directory) will now contain just
one block, but
hopefully that is the same block as in your file system, so if you may
be able to recover some
files or more importantly, the directories under root, which lead to
the entire un-wiped file system.

I would even try to manually allocate the next 11 adjacent blocks to
the root inode,
which may contain more root directory entries.

If all that fails and you still want to manually fix your file system,
the directories under root, should be the first inode in some block
group inode table,
and it's parent directory  is the root inode.
There may be a utility that can use that info to recover a file
system, but I don't know it.

I hope any of this helps.
Good luck,
Amir.



On Sat, May 7, 2011 at 3:09 AM, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> Hi.
>
> Few minutes ago, being too tired, I unfortunately did a mkfs.ext3 on an
> already existing ext3 fs (instead of fsck.ext3).
> It unfortunately didn't warn me that there's already an fs on it but
> started right away with it's evil work[0] until I ^C-ed it[0] in panic.
>
> I know this list is about devel, but unfortunately I don't know a better
> place to ask experts (sorry).
>
>
> When I scan the fs with testdisk it seems to find some superblocks, having
> the old fs label:
> superblock 32768, blocksize=4096 [data1]
> superblock 98304, blocksize=4096 [data1]
> superblock 163840, blocksize=4096 [data1]
> superblock 229376, blocksize=4096 [data1]
> superblock 294912, blocksize=4096 [data1]
> superblock 819200, blocksize=4096 [data1]
> superblock 884736, blocksize=4096 [data1]
> superblock 1605632, blocksize=4096 [data1]
> superblock 2654208, blocksize=4096 [data1]
> superblock 4096000, blocksize=4096 [data1]
>
> Could it be that these are still valid ones?
>
> When I try to mount e.g.:
> # mount -t ext3 -o sb=$((32768*4)) /dev/sdc1 /mnt/
> mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
>       missing codepage or helper program, or other error
>       In some cases useful info is found in syslog - try
>       dmesg | tail  or so
>
> ...it doesn't work however.
>
> Any ideas?
>
> Thanks,
> Chris.
>
> btw: Please CC me as I'm off list.
>
>
> [0]mke2fs 1.41.12 (17-May-2010)
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> Stride=0 blocks, Stripe width=0 blocks
> 45793280 inodes, 183143000 blocks
> 9157150 blocks (5.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=4294967296
> 5590 block groups
> 32768 blocks per group, 32768 fragments per group
> 8192 inodes per group
> Superblock backups stored on blocks:
>        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
>        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
>        102400000
>
> Writing inode tables: ^C00/5590
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mounting ext3 with another superblock doesn't work?

[Yongqiang Yang]

Hey,

You can try to restore your data with ext3_grep.  If you are lucky
enough, the journal can be found and corrupt metadata blocks can be
found in the journal, the data thus can be restored.

Good lucky.
Yongqiang.

On Sat, May 7, 2011 at 3:38 PM, Amir G. <amir73il@users.sourceforge.net> wrote:
> Hi Christoph,
>
> First, sending this question to linux-ext4 is your best bet.
> Second, I have this email from Mike, who had the exact same problem.
> I gave him some advice (off the list for some reason).
>
> So you can do one 2 things:
> 1. take comfort that you are not alone
> 2. ask Mike if my advice helped him or if he found other ways to
> overcome the problem. I think he used an LVM snapshot to make
> some experiments before actually making changing to the fs.
>
> Your situation may be even better off than Mike's.
> If you really hit ctrl-C after overwriting only super block and inode block #0,
> then you haven't really lost much 'information'
> the super block and inode block #0 from a new formatted fs, should contain
> roughly the exact same 'information', the only exception is files (not
> directories) created
> at the root dir. those file inodes information would have been been lost.
>
> Again, if you have a way to make a full backup of your drive,
> before doing any experiments, that would be wise...
> Also, when you attempt to mount the fs, better try readonly mount.
> If there are lost files or your drive, you don't want to overwrite their data.
>
> Good luck,
> Amir.
>
> ---------- Forwarded message ----------
> From: Amir Goldstein <amir73il@gmail.com>
> Date: Sun, Dec 19, 2010 at 11:01 PM
> Subject: Re: Accidental mkfs.ext4 on wrong volume already formatted with ext4...
> To: Mike Swanson <mikeonthecomputer@gmail.com>
>
>
> On Sat, Dec 18, 2010 at 12:12 PM, Mike Swanson
> <mikeonthecomputer@gmail.com> wrote:
>> Hey,
>>
>> In some stupid late night adventures, I accidentally ran mke2fs on my
>> normal /home volume (1.3TB, about 600GB used....) rather than a new
>> volume I had intended... I quickly realized my mistake and did ^C
>> though I'm not sure what my options are now for possible recovery....
>>
>> # mkfs.ext4 /dev/freedom/home
>> mke2fs 1.41.12 (17-May-2010)
>> Filesystem label=
>> OS type: Linux
>> Block size=4096 (log=2)
>> Fragment size=4096 (log=2)
>> Stride=0 blocks, Stripe width=0 blocks
>> 85196800 inodes, 340787200 blocks
>> 17039360 blocks (5.00%) reserved for the super user
>> First data block=0
>> Maximum filesystem blocks=0
>> 10400 block groups
>> 32768 blocks per group, 32768 fragments per group
>> 8192 inodes per group
>> Superblock backups stored on blocks:
>>        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
>>        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
>>        102400000, 214990848
>>
>> Writing inode tables: ^C 41/10400
>> #
>>
>> "dumpe2fs -o superblock=20480000" seems to give the old superblock
>> metadata still... filesystem create time, last write, etc, though
>> running e2fsck results in this:
>> # e2fsck -n -b 20480000 /dev/freedom/home
>> e2fsck 1.41.12 (17-May-2010)
>> Superblock has an invalid journal (inode 8).
>> Clear? no
>>
>> e2fsck: Illegal inode number while checking ext3 journal for /dev/freedom/home
>>
>>
>> I'm in a panic and I don't know what to do.. if anyone can help
>> recover data from this accident it would be much appreciated
>
> Oh, what a mess...
>
> I cannot offer you much, but I will try to assess your situation and
> offer some tips I would try.
> I do not offer fixing tools nor have those tips ever been tested by myself.
> I do hope that I am not mumbling nonsense and planting fake hopes...
>
> It appear from the logs, that you have wiped the super block and all
> of it's backups
> and the first 41 block groups inode tables.
>
> Maybe you have a working copy of your super block and maybe you don't,
> but assuming you know the parameters you used to format the partition
> in the first place, recovering a sane super block shouldn't be too hard.
> I think Fsck can fix the most of the fields later (???)
> The real problem is the lost inodes.
>
> What you know for sure is that you have wiped the root inode (2)
> resize inode (7), journal inode (8) and every file
> which was ever created in the root directory.
>
> So suppose you have the ability to format a file system , which looks the same
> as your file system when it was created (using same mkfs parameters and
> preferably the same mkfs version), you can use that to copy a sane version
> of root, resize, and journal inodes.
>
> The journal inode should be identical to the one you wiped (it never
> changes after mkfs).
> The resize inode also never changes unless you did online resize, but
> it can be fixed by fsck.
> The root inode (containing the root directory) will now contain just
> one block, but
> hopefully that is the same block as in your file system, so if you may
> be able to recover some
> files or more importantly, the directories under root, which lead to
> the entire un-wiped file system.
>
> I would even try to manually allocate the next 11 adjacent blocks to
> the root inode,
> which may contain more root directory entries.
>
> If all that fails and you still want to manually fix your file system,
> the directories under root, should be the first inode in some block
> group inode table,
> and it's parent directory  is the root inode.
> There may be a utility that can use that info to recover a file
> system, but I don't know it.
>
> I hope any of this helps.
> Good luck,
> Amir.
>
>
>
> On Sat, May 7, 2011 at 3:09 AM, Christoph Anton Mitterer
> <calestyo@scientia.net> wrote:
>> Hi.
>>
>> Few minutes ago, being too tired, I unfortunately did a mkfs.ext3 on an
>> already existing ext3 fs (instead of fsck.ext3).
>> It unfortunately didn't warn me that there's already an fs on it but
>> started right away with it's evil work[0] until I ^C-ed it[0] in panic.
>>
>> I know this list is about devel, but unfortunately I don't know a better
>> place to ask experts (sorry).
>>
>>
>> When I scan the fs with testdisk it seems to find some superblocks, having
>> the old fs label:
>> superblock 32768, blocksize=4096 [data1]
>> superblock 98304, blocksize=4096 [data1]
>> superblock 163840, blocksize=4096 [data1]
>> superblock 229376, blocksize=4096 [data1]
>> superblock 294912, blocksize=4096 [data1]
>> superblock 819200, blocksize=4096 [data1]
>> superblock 884736, blocksize=4096 [data1]
>> superblock 1605632, blocksize=4096 [data1]
>> superblock 2654208, blocksize=4096 [data1]
>> superblock 4096000, blocksize=4096 [data1]
>>
>> Could it be that these are still valid ones?
>>
>> When I try to mount e.g.:
>> # mount -t ext3 -o sb=$((32768*4)) /dev/sdc1 /mnt/
>> mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
>>       missing codepage or helper program, or other error
>>       In some cases useful info is found in syslog - try
>>       dmesg | tail  or so
>>
>> ...it doesn't work however.
>>
>> Any ideas?
>>
>> Thanks,
>> Chris.
>>
>> btw: Please CC me as I'm off list.
>>
>>
>> [0]mke2fs 1.41.12 (17-May-2010)
>> Filesystem label=
>> OS type: Linux
>> Block size=4096 (log=2)
>> Fragment size=4096 (log=2)
>> Stride=0 blocks, Stripe width=0 blocks
>> 45793280 inodes, 183143000 blocks
>> 9157150 blocks (5.00%) reserved for the super user
>> First data block=0
>> Maximum filesystem blocks=4294967296
>> 5590 block groups
>> 32768 blocks per group, 32768 fragments per group
>> 8192 inodes per group
>> Superblock backups stored on blocks:
>>        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
>>        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
>>        102400000
>>
>> Writing inode tables: ^C00/5590
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mounting ext3 with another superblock doesn't work?

[Christoph Anton Mitterer]

Hi folks.

What I did then yesterday night, was a

fsck.ext3 -b 32768 -B4096 device

There were MANY errors... (nearly all of them, that wouldn't be
automatically corrected e.g. by -p).


"Something" actually came back, though I cannot say (and probably never
will, as there are millions) whether everything came back and/or whether
the files are internally corrupted.

The problem is that the old directory structure was not recovered, but
_everything_ went into lost+found, some files directly in it (not with
their correct names but #xxxxxx numbers) and also many directories (also
with #xxxxxx numbers as names).
The directories however do contain at least some subtrees of the original
filesystem hierarchy (I mean with the correct names).

I guess there's no (automatic) way now, to get the full directory
structure as before, is there?


Of course I have some backups but unfortunately dating back to last
October (yes, I know, I'm stupid and deserved it ^^)...

Will try now to use fdupes and/or rdfind, to sort out all files that are
equal between backup and rescue fs and manually check and move back the
others (a work of some months probably ^^).


It's not that I wanna blame others (I mean being stupid is my fault), but
e2fsprogs' mkfs is really missing a check whether any known
filesystem/partition type/container (luks, lvm, mdadm, etc.) is already on
device (and a -force switch),... IIRC xfsprogs already do this more or
less.


Thanks and cheers,
Chris.

Re: mounting ext3 with another superblock doesn't work?

[Jan Kara]

  Hi,

On Sat 07-05-11 22:03:39, Christoph Anton Mitterer wrote:
> What I did then yesterday night, was a
> 
> fsck.ext3 -b 32768 -B4096 device
> 
> There were MANY errors... (nearly all of them, that wouldn't be
> automatically corrected e.g. by -p).
> 
> 
> "Something" actually came back, though I cannot say (and probably never
> will, as there are millions) whether everything came back and/or whether
> the files are internally corrupted.
> 
> The problem is that the old directory structure was not recovered, but
> _everything_ went into lost+found, some files directly in it (not with
> their correct names but #xxxxxx numbers) and also many directories (also
> with #xxxxxx numbers as names).
> The directories however do contain at least some subtrees of the original
> filesystem hierarchy (I mean with the correct names).
> 
> I guess there's no (automatic) way now, to get the full directory
> structure as before, is there?
  No, not really. Actually, contents of the files should be generally OK
because mkfs overwrites only inodes. So you have lost some files and
directories but once you have a file, it should be OK.

> Of course I have some backups but unfortunately dating back to last
> October (yes, I know, I'm stupid and deserved it ^^)...
> 
> Will try now to use fdupes and/or rdfind, to sort out all files that are
> equal between backup and rescue fs and manually check and move back the
> others (a work of some months probably ^^).
> 
> It's not that I wanna blame others (I mean being stupid is my fault), but
> e2fsprogs' mkfs is really missing a check whether any known
> filesystem/partition type/container (luks, lvm, mdadm, etc.) is already on
> device (and a -force switch),... IIRC xfsprogs already do this more or
> less.
  Yes, that would be reasonable although it might break some people's
scripts. But probably worth it anyway.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: mounting ext3 with another superblock doesn't work?

[Rogier Wolff]

On Mon, May 09, 2011 at 02:06:08PM +0200, Jan Kara wrote:
> > e2fsprogs' mkfs is really missing a check whether any known
> > filesystem/partition type/container (luks, lvm, mdadm, etc.) is already on
> > device (and a -force switch),... IIRC xfsprogs already do this more or
> > less.

>   Yes, that would be reasonable although it might break some
>   people's scripts. But probably worth it anyway.

This is a difficult change.... 

Some GUI install things already perform this check and after asking
confirmation from the user will just execute:

	mkfs.ext3 /dev/....

and expect it to make the filesystem. 

So you could add an option: 
	--check _for_existing_filesystem

But then it is quite likely that people running it manually will
forget to add the option....

	Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

Re: mounting ext3 with another superblock doesn't work?

[Christoph Anton Mitterer]

On Mon, 2011-05-09 at 14:06 +0200, Jan Kara wrote:
> Actually, contents of the files should be generally OK
> because mkfs overwrites only inodes. So you have lost some files and
> directories but once you have a file, it should be OK.
This is really some good news!! :-)
Are you sure with that? And wouldn't mean, that inodes are always
located at the same block locations?


> > It's not that I wanna blame others (I mean being stupid is my fault), but
> > e2fsprogs' mkfs is really missing a check whether any known
> > filesystem/partition type/container (luks, lvm, mdadm, etc.) is already on
> > device (and a -force switch),... IIRC xfsprogs already do this more or
> > less.
>   Yes, that would be reasonable although it might break some people's
> scripts. But probably worth it anyway.
IMHO the breakage is really justified then :-)

Especially as some of those scripts might actually do their own checks
for some filesystems, but perhaps completely forget about other
containter types (partitions, LUKS, mdadm, etc. etc.)


Cheers,
Chris.

Re: mounting ext3 with another superblock doesn't work?

[Jan Kara]

On Mon 09-05-11 14:59:29, Christoph Anton Mitterer wrote:
> On Mon, 2011-05-09 at 14:06 +0200, Jan Kara wrote:
> > Actually, contents of the files should be generally OK
> > because mkfs overwrites only inodes. So you have lost some files and
> > directories but once you have a file, it should be OK.
> This is really some good news!! :-)
> Are you sure with that? And wouldn't mean, that inodes are always
> located at the same block locations?
  Well, the block size is most likely the same (4 KB) in both the old and
the new fs (unless you tinkered with it but I don't expect that). That
defines size of a block group and thus position of inodes, bitmaps, etc.
Another variable is a number of inodes (per group). If you have an old
superblock you can compare the old and the new number of inodes and you
can be sure. Otherwise you rely on whether the math in the mkfs with which
you've originally created the fs is the same as the math in your current
mkfs (and you didn't specify any special options regarding this)...

								Honza
 
> > > It's not that I wanna blame others (I mean being stupid is my fault), but
> > > e2fsprogs' mkfs is really missing a check whether any known
> > > filesystem/partition type/container (luks, lvm, mdadm, etc.) is already on
> > > device (and a -force switch),... IIRC xfsprogs already do this more or
> > > less.
> >   Yes, that would be reasonable although it might break some people's
> > scripts. But probably worth it anyway.
> IMHO the breakage is really justified then :-)
> 
> Especially as some of those scripts might actually do their own checks
> for some filesystems, but perhaps completely forget about other
> containter types (partitions, LUKS, mdadm, etc. etc.)
> 
> 
> Cheers,
> Chris.
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: mounting ext3 with another superblock doesn't work?

[Christoph Anton Mitterer]

On Mon, 9 May 2011 15:10:27 +0200, Jan Kara <jack@suse.cz> wrote:
>   Well, the block size is most likely the same (4 KB) in both the old
and
> the new fs (unless you tinkered with it but I don't expect that). That
> defines size of a block group and thus position of inodes, bitmaps, etc.
> Another variable is a number of inodes (per group). If you have an old
> superblock you can compare the old and the new number of inodes and you
> can be sure. Otherwise you rely on whether the math in the mkfs with
which
> you've originally created the fs is the same as the math in your current
> mkfs (and you didn't specify any special options regarding this)...

Well I didn't change them but maybe Debian has modified the defaults in
mke2fs.conf since I created the fs initially.
inode_size = 256 could be a candidate. Unfortunately I don't remember
which Debian/e2fsprogs I've used to create the fs originally.

Was this ever set to 128 (i mean as a default for e2fsprogs itself, when
it was not set in mke2fs.conf)?


If the values would have actually changed, wouldn't this mean that all
data was then gone?


Cheers,
Chris

Re: mounting ext3 with another superblock doesn't work?

[Jan Kara]

On Mon 09-05-11 13:47:41, Christoph Anton Mitterer wrote:
> On Mon, 9 May 2011 15:10:27 +0200, Jan Kara <jack@suse.cz> wrote:
> >   Well, the block size is most likely the same (4 KB) in both the old
> and
> > the new fs (unless you tinkered with it but I don't expect that). That
> > defines size of a block group and thus position of inodes, bitmaps, etc.
> > Another variable is a number of inodes (per group). If you have an old
> > superblock you can compare the old and the new number of inodes and you
> > can be sure. Otherwise you rely on whether the math in the mkfs with
> which
> > you've originally created the fs is the same as the math in your current
> > mkfs (and you didn't specify any special options regarding this)...
> 
> Well I didn't change them but maybe Debian has modified the defaults in
> mke2fs.conf since I created the fs initially.
> inode_size = 256 could be a candidate. Unfortunately I don't remember
> which Debian/e2fsprogs I've used to create the fs originally.
> 
> Was this ever set to 128 (i mean as a default for e2fsprogs itself, when
> it was not set in mke2fs.conf)?
  Yes it was although relatively long time ago (several years).

> If the values would have actually changed, wouldn't this mean that all
> data was then gone?
  Not really because we store extended attributes in the additional 128
bytes of inode space and unless we see proper magic value we ignore the
contents. So you'd just silently loose every second inode I think.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: mounting ext3 with another superblock doesn't work?

[Lukas Czerner]

On Mon, 9 May 2011, Christoph Anton Mitterer wrote:

> On Mon, 2011-05-09 at 14:06 +0200, Jan Kara wrote:
> > Actually, contents of the files should be generally OK
> > because mkfs overwrites only inodes. So you have lost some files and
> > directories but once you have a file, it should be OK.
> This is really some good news!! :-)
> Are you sure with that? And wouldn't mean, that inodes are always
> located at the same block locations?
> 
> 
> > > It's not that I wanna blame others (I mean being stupid is my fault), but
> > > e2fsprogs' mkfs is really missing a check whether any known
> > > filesystem/partition type/container (luks, lvm, mdadm, etc.) is already on
> > > device (and a -force switch),... IIRC xfsprogs already do this more or
> > > less.
> >   Yes, that would be reasonable although it might break some people's
> > scripts. But probably worth it anyway.
> IMHO the breakage is really justified then :-)
> 
> Especially as some of those scripts might actually do their own checks
> for some filesystems, but perhaps completely forget about other
> containter types (partitions, LUKS, mdadm, etc. etc.)

Well, it really is not justified!. We all have testing scripts where we
just create filesystem over and over again because it is how it works,
consider xfstests for example, there are even some tests which clears
MKFS_OPTIONS completely (which should be fixet btw).

However I do agree that the change should be made, but we should
probably just print an warning first and then after some time, when
people notice that something is going to change, make that change to
refuse mkfs on existing filesystem without "-F" option.

Thanks!
-Lukas

> 
> 
> Cheers,
> Chris.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 

Re: mounting ext3 with another superblock doesn't work?

[Ted Ts'o]

On Mon, May 09, 2011 at 02:06:08PM +0200, Jan Kara wrote:
>   Yes, that would be reasonable although it might break some people's
> scripts. But probably worth it anyway.

I wouldn't object to a patch to e2fsprogs which changes mke2fs to do
this check and refuses to blow away a file system if:

[defaults]
    check_for_prexisting_fs = true

was in /etc/mke2fs.conf.

I'd also suggest that mke2fs -f NOT enable mke2fs to blow away file
systems, but that we add a new utility --- probably to util-linux-ng
--- with the destroy_partition, which a system administrator has to
explicitly run to blow away a partition.

I'd really rather not train people that mke2fs -f is the way to get
the utility to !@#@! shut up.  It's exactly the same problem with why
"alias rm 'rm -i'" doesn't work.  System administrators just get in
the habit of typing return, 'y', return, and in the end things still
just get lost.

If we have a separate utility, destroy_filesystem, which checks to see
if there is a tty, and if so, prints the details of what is on the
partition, and then forces the user to type "YES<return>", then we
have a unified way of protecting against careless sysadmins.  We can
also have that utility do clever things, such as simply telling the
hard drive to reinitiailize its crypto keys if it supports FDE, or
tell it to TRIM the entire disk if it supports TRIM/DISCARD, etc.

							- Ted