Hello!
On Tue, Feb 19, 2002 at 12:16:12AM +0100, Jens Benecke wrote:
> > This is easily reproducable on 2.5, so there is no point to do it on
> > 2.4. They 2.4 and 2.5 share most of the code, anyway.
> Right... but I'm not planning to use 2.5 any time soon. Perhaps you
> understand why if you look at www.jensbenecke.de/misc/ws02k.ps. =;)
I am not going to urge anyone to try 2.5 for any use anyway. ;)
I just made sure you was not using 2.5
> > Basically, I think if you read some errors were noticed in some
> > filesystem, and then fixed and you plan to upgrade to that kernel, it
> > is better to run fsck first, just in case. So that you are sure you
> Yes, I will next time. The problem is I (usually) upgrade only when
> I have specific problems with the current kernel, and not when I don't
> notice any problems - AND I would have about 240G of fsck to go through,
> which isn't really little.
I doubt you upgrade kernels often, then. So you probably might
do fsck in time of upgrade. It's up to you, anyway.
> > was not bitten by previous errors (and you also have perfectly valid
> > reason to argue that new fixes broke something, if new code breaks and
> > there were no errors on the filesystem before new code was run).
> The problem is, can you expect the new code to handle broken old data?
Either we can or stuff breaks and warnings/errors are displayed.
I see little reason to handle totally bogus data, in fact.
That's what fsck is for.
> Yes, I wasn't talking about hardware errors. In THEORY, this shouldn't
> happen. ReiserFS _should_ fix every file system (ie metadata) error on
> journal replay, right?
Yes. (though with HDDs that have write cache turned on by default
(and not battery backed) we may have problems here).
> But suppose it doesn't find them all, or there is an obscure bug in the
> journal code, or whatever. So next time you boot you _do_ have subtly
> broken metadata on the disk. Fsck _would_ find this, but it never gets
> executed automatically, because of journalling. So the error stays.
fsck is executed automaticly on system startup (if you have nonzero value
in fsck priority field in your fstab), it is just reiserfsck was not
trusted to be run without users' control. I hope we can get reiserfsck into
much more stable shape, then on error we'd just set "error" bit in the
superblock, and reiserfsck will do a full scan on subsequent reboot
(well may be not a full scan, but something certainly can be done here).
Right now reiserfsck exits when run from fsck -A.
> I know. I did, for exactly this reason. It's a trade-off, in some ways.
> Until somebody finds a way to lock parts of the file system in idle
> times, to do the integrity check 'live' (like scandisk does for FAT).
> Something like
> - no write access for >$TIMEOUT, and no fsck in > 1 month?
> -> remount read-only, start fsck in background
fsck on a read-only mount is not very safe either.
It can move some blocks, it can delete some stuff which kernel believes should
be here.
> on-line fsck would be just about as appreciated as on-line resizing etc,
> because it potentially saves a lot of downtime.
I believe that bug-free robust filesystem will be apperciated much more ;)
Unfortunately this goal is almost impossible to achieve.
> AND, you'd be the first, not only on Linux, to have this, AFAIK there is
> no serious file system that can do this.
FreeBSD people claim they can (or will be able soon) to have
a snapshot of their FS, they will run fsck on, while all the other stuff will
work in rw mode as usual.
Bye,
Oleg
