From: "Theodore Ts'o" <tytso@mit.edu>
To: Robert Gyazig <juliarobertz_fan@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: undo an mke2fs !!
Date: Thu, 6 Nov 2003 08:34:42 -0500 [thread overview]
Message-ID: <20031106133442.GB23624@thunk.org> (raw)
In-Reply-To: <20031106055601.75420.qmail@web21505.mail.yahoo.com>
On Wed, Nov 05, 2003 at 09:56:01PM -0800, Robert Gyazig wrote:
> Hi Ted and others,
>
> I created a new partition on my disk, and without
> noticing the change in the hdaX of the partition i did
> an mke2fs /dev/hdaX. :(
>
> Unfortunately it was my /home partition and was an
> ext3 partition earlier. Can anyone please advice on
> how to retrieve the old data.
>
> I read that mke2fs nukes all the meta information, so
> does that mean all inodes are destroyed and there is
> no hope for me ?!?!?
Unfortunately, you're correct. The location of which blocks were
associated with which inodes are irretrievably lost.
If you had backed up the metadata using an e2image command, you would
have been fine, but that command takes a while to run, so most people
don't bother to do this. (Not a bad idea for the absolute paranoids
in the house would be to run e2image out of a cron script and save the
image file on some *other* filesystem.)
I've thought about making mke2fs run e2image and saving the result
somewhere else, but that takes a long time, and people would get
annoyed if I did that. Still, enough people have gotten screwed by
this that I've been tempted to add this as an option. Another
possibility is for mke2fs to notice when the filesystem is already
formatted using ext2/3, and then printing a warning message and
waiting 10 seconds before continueing, so the user has a chance to
type control-C. This would probably be the least annoying as far as
already existing scripts that use mke2fs, although of course there
would be an option to turn this behaviour off.
> i did a cat /dev/hdaX > /dev/hdaY, which was an empty
> partition earlier so that I can play around a bit. I
> tried couple of things with debugfs but coudn't go
> much far.
You can use a disk editor to find the text strings of critical files
that you wish to rescue, and hope they were contiguously allocated,
but that's probably the best you can do....
Sorry, but that's the current Unix design philosophy, which is to
assume that the system administrator knows what he/she is doing. I
never, ever type the mke2fs command without a certain amount of fear
and trepidition, and always check and triple check before doing so.
Still, as Linux becomes more mainstream, we do need to think about
adding safety checks so that to avoid accidents by less careful system
administrators. The challenge is to figure out ways of doing so in
the least obstrusive way as possible, to avoid annoying the existing
population.
- Ted
P.S. The other approach, which might also be the right one, is to use
a front-end program --- call it newfs --- which does many more safety
checks and which could do things like use e2image to backup the inode
blocks before doing an mke2fs. That way, administrators can choose
whether they want the additional safety checks or not.
next prev parent reply other threads:[~2003-11-06 13:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-06 5:56 undo an mke2fs !! Robert Gyazig
2003-11-06 13:34 ` Theodore Ts'o [this message]
2003-11-06 14:25 ` Ingo Oeser
2003-11-06 15:01 ` Pavel Machek
2003-11-06 17:22 ` Theodore Ts'o
2003-11-06 19:21 ` Pavel Machek
2003-11-07 10:33 ` Geert Uytterhoeven
2003-11-07 10:48 ` Pavel Machek
2003-11-07 19:58 ` Theodore Ts'o
2003-11-06 16:54 ` Maciej Zenczykowski
2003-11-07 4:35 ` Szakacsits Szabolcs
2003-11-07 5:00 ` Nathan Scott
2003-11-07 5:43 ` Szakacsits Szabolcs
2003-11-07 5:52 ` Nathan Scott
2003-11-07 23:13 ` Andrew Pimlott
2003-11-08 15:02 ` Szakacsits Szabolcs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031106133442.GB23624@thunk.org \
--to=tytso@mit.edu \
--cc=juliarobertz_fan@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.