Hello Radu,
I do not know what level you are at with this, and I do not know if your
objective is to try and get ext3 to work with bad blocks as a development
exercise, but my response is to aid in the scenario that this is a
production machine and your filesystem is in trouble.
At this point, I would not waste cycles trying to recover the filesystem
unless you are already at the forensics stage.
After you recover your data you will not be trying to use the same disk
again.
That would be asking for trouble.
So, your objective here is to simply mount the filesystem and extract the
data you want, copy it to a healthy disk, and then discard the old disk,
right?
That being said, I would boot from a rescue disk (if this is also your root
filesystem), mount the bad drive with "mount -t ext2 /dev/hdc3 /mnt/drive
-o
ro" and then copy your data which hopefully is not damaged, to the new
mount
drive which you just have prepared and mounted for this exercise.
Notice I have mounted the drive as ext2 above. Ext3 is simply ext2 plus a
journal. Since your journal is not functioning, it does not make sense to
mount with that bad journal and use it. We are just doing read-only access
here anyways.
Do not copy by a filesystem dump or block copying your partition. You want
to logically move the files with 'cp'. Otherwise, your problems will
follow.
If the file cannot be read while the copy is taking place, you have a
genuine problem with the file on the broken filesystem, and then your next
step would be to THEN do filesystem forensics.
If your data truly is damaged, an fsck will likely not restore it, and from
the looks of your warning messages below, your journal is bunked as well.
The biggest benefit of running fsck at this point would be to restore the
filesystem so you can continue using it, which I would strongly advise
against if this is a production machine.
There are mood points where fsck can grant you a full usable file again
which has otherwise been bunked by bad nodes or bitmaps, but the exceptions
fall into forensics which can get deep.
If you still want to do a filesystem fix, try using e2fsck -c option to
check for badblocks and mark them while this is done. Sort of adds that
Windows disk checking nicety about it ;)
You can also tell it where your journal is with e2fsck -j <journal>, but
you
really want to do this without a journal if it is broke, which takes us back
to ext2 again.
You can try using "tune2fs -j" to create a new journal going from ext2
to
ext3, but I have not played much with these options for bunked filesystems,
as of yet. Typically at this point, we are trying to recover data safely.
Good Luck!
Arthur Perry - Linux Engineer, Perry Consulting Services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Need Linux consulting? I can help!
Email me at alp@perryconsulting.net.
I can also make contract visits to your site to help you plan your
infrastructure, or give you emergency aid.
With nearly 6 years experience in Linux and even more than that in other
discipline disaster recovery, I may be able to help your enterprise with a
simple phone call.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: ext3-users-admin@redhat.com [mailto:ext3-users-admin@redhat.com]On
Behalf Of Radu Rendec
Sent: Thursday, November 14, 2002 10:46 AM
To: ext3-users@redhat.com
Subject: Problem recovering ext3 filesystem
Hi,
I have a 20GB partition on a hard disk that just developed bad blocks.
Fortunately, I had backups for the most important data on it, but I'd
like to recover some files that were too large to backup.
When running 'e2fsck /dev/hdc3', I get the following message:
e2fsck 1.27 (8-Mar-2002)
Group descriptors look bad... trying backup blocks...
e2fsck: Invalid argument while checking ext3 journal for /
I already made a backup copy of the whole partition. I also tried to
copy the partition on a new disk and run e2fsck on the new disk. I was
hoping the error message was caused by e2fsck not being able to read
some of the journal's blocks.
Do you have any suggestions about the way I could recover the
filesystem?
Thanks,
Radu Rendec