[openbeos] Re: Robustness
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 08 Apr 2002 21:40:54 +0200 (MEST)
IMHO the best behaviour would be :
in bfs:
bool error_while_mounting = false;
// ...
// check super block, other structs
if (error_while_mounting && !force_rw) // force_rw is a kernel param at boot
mount_ro = true; // could happen even after mounting, whenever we encounter
a really bad thing
in BootScript:
iw=`/bin/isvolume -readonly /boot`
if [ "$iw"x = "yes"x ]
then
hasprobs=`/bin/isvolume -failing /boot` # new param
if [ "$hasprobs"x != "yes"x ]
then
launchscript $SCRIPTS/Bootscript.cd
exit # in case it returns...
fi
fi
#later, after app_server starts
if [ "$hasprobs"x = "yes"x ]
then
alert "Your boot filesystem is corrupted and has been mounted
read-only. You should backup all important data IMMEDIATELY."
fi
En réponse à Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> > > If there is a bigger problem, it makes sense to let you not even
> > > mount
> > > that disk (as long as there are proper tools to save all important
>
> > > data
> > > from that disk).
> > Your vision is a little too simplist, my experience showed me that
> > when your harddisk start to 'die', you simply don't know it.
> > It's only when you start your computer a day, that you see
> > that something goes really really wrong, so, the filesystem
> > SHOULD be robust enough to allow you to mount and read (and save
> > somewhere)
> > your data, and not just say "Hey guy, your harddisk is dead, use
> > the the tool XYZ (which is often in the dead partition :) )".
> > Often just 1 or 2 files are corrupted, but even if 98% of the files
> > are
> > dead, the FS must give you read access to the 2% still Ok.
> > No need to use a dedicated tool for recovery, the FS has to be
> > secure enough to mount with read only (or write for excellent FS)
> > access corrupted harddisk, if not, it's just another "MS FS".
>
> I have thought on adding such functionality to the fs (as I've written
>
> such tools), but I am really against it. And this has nothing to do
> with simplicity.
> IMHO a fs *should* not be able to read corrupt disks - robustness means
>
> that it shouldn't crash when it tries to read corrupt data, it does not
>
> mean it should be able to read every piece of crap you're throwing at
> it, it should only be able to deal with it. IMO only a bad fs would
> allow you to have write access on such a disk. Not being able to work
> normally with your disk in case of a hardware failure is a feature, not
>
> a bug.
>
> I would prefer a car that won't let me use it when it's clear that it
> will not survive the next tour - and with a fs it's even nicer, because
>
> saving your old data doesn't cost anything in that case (but it does if
>
> your harddrive really died).
>
> Not letting you mount in that case is a way to ensure robustness. A
> dying harddrive isn't robust, let's face it. Or from a programmer's
> POV: I like assert()s, or that segfaults, and "the looper must be
> locked" kind of error messages - they help assuring robustness, even if
>
> may be inconvenient for the user in the first place.
>
> If you're fs would let you work normally, you would just wait until the
>
> real accident will happen - if it had interrupted you before, you could
>
> have saved all your precious data at that point, now it's gone forever.
>
> This has nothing to do with MS which doesn't work even if there is
> nothing wrong. And even MS has learnt a lot since FAT.
>
> Adios...
> Axel.
>
>
>
>
Other related posts:
