On Sat, 23 Sep 2000, John Summerfield wrote:
>> So something like: e2fsck -p -y /dev/hda1
>>
>> That automatically answers yes to all questions and repairs
>> without questions. This doesn't mean that the filesystem will be
>> in a state that is useful when it is done though. fsck asks you
>
>Ah.
>
>And what do you do when it says, "%s: UNEXPECTED INCONSISTENCY; RUN fsck
>MANUALLY.
>(i.e., without -a or -p options)," as happened to me?
>
>I've seen this two or three times.
If it says that, it means that you should look at each error and
be the judge of how to fix it to ensure maximal recovery. If you
can't decide, then no matter how you slice it you'll likely end
up with some data loss or in the worst case complete corruption.
The only way to avoid these scenarios, is to avoid whatever
caused the fs to be uncleanly unmounted. If this is power out, a
UPS is ideal, but perhaps cost prohibative. Of course Reiserfs
or ext3 are alternatives worth considering as well. (which the
subject originated with. ;o)
If you use straight ext2 though and can't prevent filesystems
from being yanked, or perhaps can't prevent some kernel crash
from occuring, fsck is a fact of life. If it occurs often, and
this is for business use, you might seriously consider better
solutions. If it is a home box, play with reiser or ext3 and you
should be ok. I'm using reiserfs right now and having no
problems with it. None that I've noticed anyways. ;o)
>Oh, and what do you do when the files in lost+found cannot be deleted (I
>forget whether it was "invalid operation" or "permission denied" - I was root
>at the time.
That is generally a sign of some serious disk corruption. The
type that occurs when one uses evil settings on hdparm. ;o)
There are howtos on this sort of thing, but in general it is not
for the faint of heart and often requires a more in depth
understanding of the on-disk ext2 disk structures, and some fancy
usage of the 'debugfs' program. This is not for the end user
however by far. I myself stay away from low level stuff like
that whenever possible, but if I had to, I could pull up the
manpage from another machine, and hack away for a while and
likely get by.
If you see oddball permissions, or files are undeleteable,
etc.. you might also try the "chattr" command to clear the
extended attributes first. If that doesn't work, often debugfs
is the only recourse, or a full backup/format/restore.
>It was when I saw the file dates in there that I figured I could not trust
>anything on that partition.
Most likely that was a very good assumption. If you see files
with "?" as their filetype similar to this:
?rwx--x-wx and random looking perms, etc.. or perhaps filesizes
listed like 4254234532 or some insane large numbers, etc.. it is
most likely disk corruption. Backup tapes/disks are your friend
here. ;o)
Just remember, fsck is only a tool, and it can only do so
much. If your disk has met the electronic mix-master, then fsck
will likely be of little or no use. There are solutions however
to ensure data reliability and integrity, should that be
necessary for the job at hand. One must weigh the costs with the
risk assessment however.
I hope this helps,
Take care.
TTYL
--
Mike A. Harris - Linux advocate - Open source advocate
Copyright 2000 all rights reserved
----------
#[Mike A. Harris bash tip #1 - separate history files per virtual console]
# Put the following at the bottom of your ~/.bash_profile
[ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir
tty |grep "^/dev/tty[0-9]" >& /dev/null && \
export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///')
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
