From: drew@romeo.cs.colorado.edu (Drew Eckhardt) Subject: Re: how to repair an ext2fs Date: Sat, 7 Aug 1993 14:00:43 GMT
In article <23tndp$1oa@nz12.rz.uni-karlsruhe.de> "Gerd Klesse" <LH04@IBM3090.RZ.UNI-KARLSRUHE.DE> writes:
> Hi Linuxers!
>
>I have recently run 'e2fsck -v /dev/hda2' which is my
>root file system. I use only '-v' since it got damaged one time
>when I did 'e2fsck -rv /dev/dha2' and killed me the directory
>/usr/local with all extra installed software.
Was it mounted when you had open files on the disk? After you'd
written to it? Both are real bad.
1. Your filesystem was probably corrupt, you wrote to it while
it was still corrupt, it got corrupted furthur, and the e2fsck
had to remove the /usr/local directory because of the corruption.
2. The Unix filesystem has two layers of "namespace"
At the lowest layer, files are indexed numerically, and each
file (refered to as an inode) has an associated type (ie, normal,
symbolic link, etc), mapping of blocks, modification and access
times, etc.
At the top layer, there is a tree of directory files starting
at the root inode, which do a name to inode translation. If
these files become damaged, and the fsck program notices inodes
with no directory entries, it will make entries for them under
lost+found. Note that if the directory entry for a directory is
lost, the directory inode still exists and files in that directory
will have their names intact.
So, you probably got a block in both /usr/local and some other
file, and e2fsck had to unlink /usr/local. However, if you
looked under lost+found, you could have figured out what
everything was with no problems.
>How can I safely repair a dammaged ext2fs without using e2fsck?
Get out your sector editor, and using the Linux code as a road map,
manually repair the disk.
In other words, for all practical purposes, you don't. Use e2fsck,
and it wil repair the dammage. However, if you actually wrote to
a damaged filesystem after it was corrupted, the damage could be
quite severe.
>By the way -- no data seems to be lost by now.
>But one never knows...
Yes.
I can't emphasize this point more strongly without shouting, which
could cause unecessary eye strain :
Run e2fsck -a out of /etc/rc, automatically, even if you have gigabytes of
disk and it takes 15 minutes for your system to come up. The unix
filesystem is very robust, and if you repair it after a crash / bad
power off you will only loose files actually being written at the time
of the crash. If you don't, corruption will breed corruption and you will
loose data as a corrupt free map results in blocks being assigned to
multiple files, and you will install from tape backup.
If you always shutdown cleanly, e2fsck will see the clean flag and
won't check the partition, it is also safe to make the running of the
fsck programs conditional on the non-existance of /fastboot, in all
other cases e2fsck MUST run or you WILL eventually loose data.
>And I don't want to reinstall the whole system anew.
After e2fsck repairs the damage that's been building up, it may be
the easiest solution (remember that inodes with no directory entries
will be in lost+found at the root of the file system).
Always run fsck automatically when you boot, and do it before you write
to the fs (ie, generally this means fsck is only run on unmounted
filesystems, root is generally mounted read-only, and some unices reboot
if there are errors).
-- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Condemn Colorado for Amendment Two. | Drew Eckhardt Use Linux, the fast, flexible, and free 386 unix | drew@cs.Colorado.EDU Will administer Unix for food |