Re: How errorproof is ext2 fs?

[Frank Schneider]

Rogier Wolff schrieb:
> 
> Alan Cox wrote:
> > > due to an not responding USB-keyboard/-mouse (what a nice coincident). Now while
> > > the Mac restarted without any fuse I had to fix the ext2-fs manually for about
> > > 15 min. Luckily it seems I haven't lost anything on both system.
> > >
> > > This leaves me a bad taste of Linux in my mouth. Does ext2 fs really behave so
> > > worse in case of a crash? Okay Linux does not crash that often as MacOS does, so
> 
> > That sounds like it behaved well. fsck didnt have enough info to safely
> > do all the fixup without asking you. Its not a reliability issue as such.
> 
> Well, fsck wants to ask
> 
>         "Found an unattached inode, connect to lost+found?"
> 
> to the user and will interrupt an automatic reboot for that.
> 
> This is bad: The safe choice is safe: It won't cause data-loss.
> 
> Maybe it should report it (say by Email), but interrupting a reboot
> just for connecting a couple of files to lost+found, that's
> rediculous.
> 
> If it would give me enough information when I do this manually, I'd
> make an informed decision. However, what are the chances of me knowing
> that inode 123456 is a staroffice bak-file? So the only way to safely
> operate is to link them into lost+found, and then to look at the files
> manually.

Hello...

This is true, most distros are relatively rigid in dropping you to a
shell, because they call fsck with very weak options and do not care
about the fact that most servers are not standing under a table of
someone with easy access to the console.

If i have such a problem and get dropped to a shell, i normaly do a
simple "e2fsck /dev/XXX -p" or "-y" and this runs through and fixes the
filesystem without any questions.

I had only one time in the recent history where this did not work, i had
to repeat the steps a second and third time, but that was due to an
extreme error, i did e2fsck on a mounted filesystem during writing
.tar-backups there (error in crontab)...no good idea..:-).

So if you want to come around this "dropping-you-to-a-shell" problem you
could easily patch the file "/etc/rc.d/rc.sysinit" (RH) and call fsck
with the option "-p" or "-y", and you could easily change this script
that in cases of really bad trouble the system mounts / (or a
reserve-partition, even a CD would do AFAIK) readonly but starts up
normaly, so you can log in via net and do the repair by hand.

Solong..
Frank.

--
Frank Schneider, <[e-mail]>.                           
... -.-