Hello!
On Tue, Feb 11, 2003 at 05:24:58AM +1300, Sam Vilain wrote:
> > > Therefore, your reiserfsck has a bug. The whole point of a fsck is
> > Well, currently the logic is "If we cannot read some block, that
> > usually means this is a badblock".
> > And so it prints the message. Of course more testing about
> > if the block is beyond partition boundary should be probably added.
> The block is not bad, it's EINVAL :-). The block *number* is bad; you
Sure.
> *could* add to your is_block_shagged() function a test for whether the
> block is out of bounds, but the point is that if it gets as far as that
> function, chances are that it is too late.
This is being worked on currently.
> (In reiserfsck), you need to do the bounds check when the referring
> block/data structure is checked.
Sure. We have some checks, though apparently not enough.
[horrors about recompiling fsck with customly disabled stuff skipped].
If you really decided to shoot yourself in the foot, you might as well
just will journal with zeroes. It would be much easier this way ;)
> - filesystem now mounts, however about the first 2 levels of directories,
> and many recently written files, have had their directory entries
> lost - lost+found contains roughly 11,000 entries (of 150,000 or
> so).
Hm, probably corresponding blocks (with names) were only present in
journal, and you erased that.
> - thankfully, I can locate the several hundred megabytes of .debs to save
> myself spending days re-downloading it all over 56k :-). Mission
> successful.
At least you have not lost anything valuable. This is good.
> If reiserfsck was built with --no-journal-available in mind (that is,
> ignoring the data present in an in-partition journal with that switch),
> then I'm fairly sure that I wouldn't have suffered the last problem.
How so?
> After the first scan, the journal would have been written back to an empty
> state.
So what? If directories content was only present in journal, you just loose that info.
> > > I'm going to try removing that test in the 3.x.1b version and see if
> > > the fsck completes.
> > Well, 3.x.1b should not be actually used, lots of bugs were fixed since
> > then.
> > Vitaly: We need a check that journal target block is in range of
> > filesystem. Please add this test.
> That is not all you must do!
> You need to do one, preferably both of the following:
> a) allow reiserfsck to ignore the in-partition journal, without producing
> an insane result (where the filesystem header says there is a journal,
> but the space where the journal is has filesystem data in it).
This cannot happen in any sane way. (I mean root block just cannot live in journal).
> b) make reiserfsck validate the journal as well as the filesystem,
> probably playing them back itself rather than relying on a mount
> option that just does the playback for it. In theory you could decide
> whether to use the on-disk or the in-journal data structure, depending
> on which was more consistent!
I was thinking about that already. May be we will do something like that in 2.7/2.8,
but certainly not now. And it will make lots of complications, I fear.
People who will forget to upgrade their reiserfsprogs will get in trouble when
upgrading kernels and so on...
Bye,
Oleg
