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 _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
