Re: Gnu Parted error, Kernel Panic, Reiserfs

[Yury Umanets <umka@namesys.com>]

On Fri, 2004-04-16 at 14:30, Szakacsits Szabolcs wrote:
> On Fri, 16 Apr 2004, Yury Umanets wrote:
> > 
> > I'm on-like, but seems missed mentioned emails somehow.
> 
> You answered the same. I've never resized reiserfs so I don't know. I'm
> just seeing the issue popping up everywhere. 

What I can say, I have not seen any details, sorry. Only claims that
there are some problems and promises that details will be presented. 

But anyway, send me emails to the following addresses:

umka@namesys.com
umka@clustrefs.com
torque@ukrpost.ent

I hope at least one should be okay..

>  
> > But I should say that I have no any details and moreover, nobody was so
> > kind to send me at least something but complains that it does not work,
> 
> Is there a test suite for resizing?


>  Just running it against recent/latest
> reiserfs could catch potential compatibility problems.

reiserfsck is perfect tool for testing resizer ;)

Yes, but I can't reproduce the problem. I tried to do it recently.
Problem may be the following:

(1) inconsistent reiserfs partition _before_ resizing. This will lead
for errors for sure. It is due the fact, that progsreiserfs resize code
has no code for checking tree validness before resizing. 

But at least node levels should be checked, because they are used for
making decision what to do on particular level of tree. And if node
level invalid resizer will get out with complains that invalid node is
found and tree will be left in invalid state.

So, as you can see, this is quite possible to be stumbled here.

(2) it is quite possible that there is a bug in resizer code, which can
only be visible on _big_ partitions. And I have not such a big
partitions to check it.


> 
> > What I need to know is the following:
> > 
> > (1) was reiserfs consistent before resizing or not (what last reiserfsck
> > said before resizing).
> 
> Running fsck before resizing is a very good practice. But most people
> don't do it so some consistent check should be done in the resizer. IMHO
> at least you must check you can account for all blocks in use. If not then
> you must decline to resize otherwise you will probably trash the fs.
Of course there are some checks. But they are not sufficient. They only
check if filesystem is consistent or not (flag in super block).

> 
> ntfsresize had this from day 0 and caught a lot of inconsistent
> filesystems (and bugs during development) and refused to resize. 
> After people run chkdsk everything worked fine.
> 
> Partition Magic didn't have this or it's optional (I don't have it but
> people said so) and I suspect that's one of the reasons it also trashes
> filesystems occasionally.
> 
> > (2) what version of reiserfs was used.
> > (3) sequence of actions or/and detailed description of what was done.
> > (4) is it visible using both parted and qtparted?
> 
> I've seen it reported with both tools. E.g. here are some qtparted ones.
> 
> 	http://qtparted.sourceforge.net/forums/viewtopic.php?t=62
> 
>     Szaka
Okay, I see what we (me) have to do. First of all I will add some code,
which will check tree for consistency. This is very simple check, not so
sophisticated as reiserfsck does. I will only check node levels, node
pointer items and probably validness of indirect items.

And if check will not pass user will be asked to run fsck first.
Actually this functionality already exists in parted. Only thing to be
done is tree check. 

Will do it in week and then will see what happen. Okay?

Thanks.

-- 
umka