r5 hash detected, unable to force r5 hash

r5 hash detected, unable to force r5 hash

[Frederick Page]

G'day everybody,

I'm using GNU Debian 2.4.13-ac8 with (included) reiserfs 3.6.25, I
created the partition with "mkreiserfs /dev/sdb1" (defaults) (defaults)
(defaults) (defaults) (defaults) (defaults) (defaults) (defaults) and
mounted like this (/etc/fstab):

/dev/sdb1   /sound    reiserfs defaults   0    1

Everything worked fine, I have the freedb database with 550,000 small
files on /sound, performance was much better than ext2. I then read
about different hashes, umounted /sound, edited fstab and remounted
it.

/dev/sdb1   /sound    reiserfs hash=tea   0    1

Mount was successful, however I only got the root-directories with "no
such file". Well, just change fstab to "hash=r5", things should be back
to normal. I then tried to mount /sound, realized, that it was still
mounted. 

Now I may have committed a big mistake: I just umounted /sound (although
fstab was already showing r5, but volume was still mounted with tea).

Then mounted again (fstab still showing r5) and got:

REISERFS: Error, r5 hash detected, unable to force r5 hash

"debugreiserfs /dev/sdb1" says:
Hash function used to sort names: "tea"

Since then, I am unable to change the hash, I can mount the partition
with "hash=detect" or "hash=tea", but then I cannot retrieve any data.

I researched via Google and the archive of this mailing list, found out
that the above error is quite old (probably fixed by now). I also
followed the advice on the main page to use kernel 2.4.18 because of
bug-fixes, but this did not change anything, I am unable to mount with
r5 hash.  (ReiserFS is still version 3.6.25 with kernel 2.4.18).

"reiserfsck --check /dev/sdb1" gives lots and lots of errors and the
recommendation to rebuild the tree (which I did not do, because I am not
sure, whether this might do more harm than good in this case).

I would very much appreciate any help, as I am struggling for my data.

Thanks for reading all this and kind regards

Frederick

Re: r5 hash detected, unable to force r5 hash

[Arthur Erhardt]

On Fri, Apr 19, 2002 at 08:57:15PM +0200, Frederick Page wrote:
: G'day everybody,
: 
: I'm using GNU Debian 2.4.13-ac8 with (included) reiserfs 3.6.25, I
: created the partition with "mkreiserfs /dev/sdb1" (defaults) (defaults)
: (defaults) (defaults) (defaults) (defaults) (defaults) (defaults) and
: mounted like this (/etc/fstab):
: 
: /dev/sdb1   /sound    reiserfs defaults   0    1
: 
: Everything worked fine, I have the freedb database with 550,000 small
: files on /sound, performance was much better than ext2.
Uh. Is it possible to create a backup of the partition in question
 (with dd) before continuing? Or do you have a backup of that data?

I won't give any other advice on how to proceed, since I'm sure 
the reiserfs team knows better than me.

Regards,

Arthur

-- 
arthur dot erhardt at pit dot physik dot uni dash tuebingen dot de 
*pgp key available*                                         dg7sea

A physicist is an atom's way of knowing about atoms.

Re: r5 hash detected, unable to force r5 hash

[Frederick Page]

Hi Arthur,

Arthur Erhardt wrote on Sat, Apr 20 2002:

>Uh. Is it possible to create a backup of the partition in question
> (with dd) before continuing? Or do you have a backup of that data?

I'm not sure, if a "dd" copy would be useful (in case I mess up things
completely). Unfortunately, I do not have a backup of the partition,
it's "just" sound. I would normally recreate it from scratch, but I'd
hate to lose all my mp3 songs and a few other things on it. Of course
I made a mistake by playing with the hash algorithms, I still wonder,
why I was able to change it from r5 to tea, but unable to change it
back. It is entirely my fault, and since I have no backup, I'm really
sweating now ;-)

As long as there's a chance of at least a read-only access, I'd hate
to resort to permanent solutions. Maybe I see things too simple, but
in my unprofessional opinion: wouldn't it suffice to just hex-edit the
r5 flag into the superblock? (If so, I'd appreciate any tips on how to
do this).

I found an old mail on this list (September 2001), according to this
mail, the feature (?) "r5 detected, unable to force r5" is unintended.

>I won't give any other advice on how to proceed, since I'm sure 
>the reiserfs team knows better than me.

Thank you anyway, nice to see that someone does care.

Kind regards     Frederick

Re: Re: r5 hash detected, unable to force r5 hash

[Manuel Krause]

Hi Frederick!

On 04/20/2002 01:59 AM, Frederick Page wrote:

> Hi Arthur,
> 
> Arthur Erhardt wrote on Sat, Apr 20 2002:
> 
> 
>>Uh. Is it possible to create a backup of the partition in question
>>(with dd) before continuing? Or do you have a backup of that data?
>>
> 
> I'm not sure, if a "dd" copy would be useful (in case I mess up things
> completely). Unfortunately, I do not have a backup of the partition,
> it's "just" sound. I would normally recreate it from scratch, but I'd
> hate to lose all my mp3 songs and a few other things on it. Of course
> I made a mistake by playing with the hash algorithms, I still wonder,
> why I was able to change it from r5 to tea, but unable to change it
> back. It is entirely my fault, and since I have no backup, I'm really
> sweating now ;-)


When you have no backup in handy and want to try reiserfsck on this 
partition make a dd copy of it before, if you have enough disk space. 
The dd won't change the disk content.

Maybe you can get the newest reiserfsprogs and reiserfsck --rebuild-tree 
can fix the false entries. Otherwise you may need to wait for the 
reiserfs teams help. Maybe you can provide the error messages of 
reiserfsck --check and your actual reiserfsprogs version number until then.

My own experiences of the latest reiserfsck beta are very good, it's 
fast, and most things put to /lost+found are recoverable (if you can 
relate them to the original files) and I found nothing was missing.

> 
> As long as there's a chance of at least a read-only access, I'd hate
> to resort to permanent solutions. Maybe I see things too simple, but
> in my unprofessional opinion: wouldn't it suffice to just hex-edit the
> r5 flag into the superblock? (If so, I'd appreciate any tips on how to
> do this).
> 
> I found an old mail on this list (September 2001), according to this
> mail, the feature (?) "r5 detected, unable to force r5" is unintended.
> 
> 
>>I won't give any other advice on how to proceed, since I'm sure 
>>the reiserfs team knows better than me.
>>
> 
> Thank you anyway, nice to see that someone does care.
> 
> Kind regards     Frederick
> 


Best wishes,

Manuel

Re: Re: r5 hash detected, unable to force r5 hash

[Arthur Erhardt]

On Sat, Apr 20, 2002 at 01:59:14AM +0200, Frederick Page wrote:
: Hi Arthur,
: 
: Arthur Erhardt wrote on Sat, Apr 20 2002:
: 
: >Uh. Is it possible to create a backup of the partition in question
: > (with dd) before continuing? Or do you have a backup of that data?
: 
: I'm not sure, if a "dd" copy would be useful (in case I mess up things
: completely).
Yes, it would. You can make one mistake, learn what you did wrong, and
restart from the current situation. 
So, if diskspace is available, do 
dd if=/dev/sdb1 of=/some/place/where/there/is/enough/free/diskspace
Note: There are some older Distributions around where glibc will
prevent you from creating files larger than 2 GB (even though you
have kernel 2.4 and reiserfs v3.6).
In that case, (a) ask again, or
(b) use this:
dd if=/dev/sdb1 |(cd /muchspace ; split -b 2000000000 - )
/muchspace/ will fill with files named xaa, xab, xac, ...
all except the last one 2*10^9 bytes in size.

: Unfortunately, I do not have a backup of the partition,
: it's "just" sound. 
Bad luck :-(

Arthur

-- 
arthur dot erhardt at pit dot physik dot uni dash tuebingen dot de 
*pgp key available*                                         dg7sea

A physicist is an atom's way of knowing about atoms.

Re: r5 hash detected, unable to force r5 hash

[Oleg Drokin]

Hello!

   This is user error.
   Because it is clearly stated that if you want to convert to new hash,
   you need to backup your data, reformat FS with new hash and put all the
   data back.

   User errors are dealt with based on http://namesys.com/support.html
   terms.

Bye,
    Oleg
On Fri, Apr 19, 2002 at 08:57:15PM +0200, Frederick Page wrote:
> G'day everybody,
> 
> I'm using GNU Debian 2.4.13-ac8 with (included) reiserfs 3.6.25, I
> created the partition with "mkreiserfs /dev/sdb1" (defaults) (defaults)
> (defaults) (defaults) (defaults) (defaults) (defaults) (defaults) and
> mounted like this (/etc/fstab):
> 
> /dev/sdb1   /sound    reiserfs defaults   0    1
> 
> Everything worked fine, I have the freedb database with 550,000 small
> files on /sound, performance was much better than ext2. I then read
> about different hashes, umounted /sound, edited fstab and remounted
> it.
> 
> /dev/sdb1   /sound    reiserfs hash=tea   0    1
> 
> Mount was successful, however I only got the root-directories with "no
> such file". Well, just change fstab to "hash=r5", things should be back
> to normal. I then tried to mount /sound, realized, that it was still
> mounted. 
> 
> Now I may have committed a big mistake: I just umounted /sound (although
> fstab was already showing r5, but volume was still mounted with tea).
> 
> Then mounted again (fstab still showing r5) and got:
> 
> REISERFS: Error, r5 hash detected, unable to force r5 hash
> 
> "debugreiserfs /dev/sdb1" says:
> Hash function used to sort names: "tea"
> 
> Since then, I am unable to change the hash, I can mount the partition
> with "hash=detect" or "hash=tea", but then I cannot retrieve any data.
> 
> I researched via Google and the archive of this mailing list, found out
> that the above error is quite old (probably fixed by now). I also
> followed the advice on the main page to use kernel 2.4.18 because of
> bug-fixes, but this did not change anything, I am unable to mount with
> r5 hash.  (ReiserFS is still version 3.6.25 with kernel 2.4.18).
> 
> "reiserfsck --check /dev/sdb1" gives lots and lots of errors and the
> recommendation to rebuild the tree (which I did not do, because I am not
> sure, whether this might do more harm than good in this case).
> 
> I would very much appreciate any help, as I am struggling for my data.
> 
> Thanks for reading all this and kind regards
> 
> Frederick
> 
> 

Re: r5 hash detected, unable to force r5 hash

[Frederick Page]

Hi Oleg,

Oleg Drokin wrote on Sat, Apr 20 2002:

>   This is user error.

Agreed.

>   Because it is clearly stated that if you want to convert to new hash,
>   you need to backup your data, reformat FS with new hash and put all the
>   data back.

I am still unable to find this in the docs. Could you please tell me,
which FM I obviously did not read?

>   User errors are dealt with based on http://namesys.com/support.html
>   terms.

Feature: you can change the hash once, but then are stuck with it, you
cannot change it back (unless you rebuild the tree).

Feature: mount does not give you any hint, that you are doing
something potentially harmful, which cannot be undone (reiserfsck does).

Feature: the documented mount-option "hash=r5" does not work, instead
gives message "error, r5 hash detected, unable to force r5 hash" (what
the message mean?). It even does this, when r5 is already in the
superblock.

Feature: this "r5 detected, unable ..." persists since at least
September 2001.


I really do appreciate your feedback, but at least I see a possibility
for the developer-team to improve reiserfs further. Please don't get
me wrong: I do not blame the reiserfs-guys for anything, I did change
the hash without full knowledge about what I was going to do (that's
clearly my mistake).

At least the mount-option "hash=r5" definately does *not* work as
documented. I'm still a little bit puzzled, why you did not even
acknowledge that, but put the blame entirely on me.

Kind regards

Frederick

Re: r5 hash detected, unable to force r5 hash

[Oleg Drokin]

Hello!

On Sat, Apr 20, 2002 at 09:00:25PM +0200, Frederick Page wrote:
> >   Because it is clearly stated that if you want to convert to new hash,
> >   you need to backup your data, reformat FS with new hash and put all the
> >   data back.
> I am still unable to find this in the docs. Could you please tell me,
> which FM I obviously did not read?

http://www.namesys.com/download.html lists linux kernel v2.4.18 as the
recommended one.
Also I remember it was mentioned somewhere that you cannot change hash that
lightly (because I have learnt this info from somewhere ;) ), but
I cannot find exact document right now.
I will look deeply at Monday though.
Man page certainly needs to clearly state you cannot change hash that easy.
We will deal with it.

> >   User errors are dealt with based on http://namesys.com/support.html
> >   terms.
> Feature: you can change the hash once, but then are stuck with it, you
> cannot change it back (unless you rebuild the tree).

Nope. You hit the kernel error that was fixed already.
Fix went into 2.4.19-pre3 kernel, or thereabout. Though it was
available as separate patch long before that.

> Feature: mount does not give you any hint, that you are doing
> something potentially harmful, which cannot be undone (reiserfsck does).

Mount have nothing to do with it, it does not know anything about mount
options.
That was a kernel bug that allowed you to change a hash.

> Feature: the documented mount-option "hash=r5" does not work, instead
> gives message "error, r5 hash detected, unable to force r5 hash" (what
> the message mean?). It even does this, when r5 is already in the
> superblock.

This is kernel error that is already fixed.

> Feature: this "r5 detected, unable ..." persists since at least
> September 2001.

Obviously because nobody tried to used that before, I presume?

> I really do appreciate your feedback, but at least I see a possibility
> for the developer-team to improve reiserfs further. Please don't get

Sure. There is always space to improve.
Thank you very much for your feedback.

> At least the mount-option "hash=r5" definately does *not* work as
> documented. I'm still a little bit puzzled, why you did not even

It did not work, I'd say.

> acknowledge that, but put the blame entirely on me.

If we won't do that, how can we collect our support money then? (joke).

Seriously, you run old kernel, went into problems, and instead of upgrading
to recommended kernel with recommended patches you just wrote your original
letter.
I think Linux is mostly "do/figure out it yourself" thing, you are either able
to solve your problems based on information located elsewhere, or just
do not touch anything without consulting with knowledgeable person.
If you touched something you was not sure about and it broke - bah, bad luck.

Times are changing, of course, no wonder about that.

Bye,
    Oleg

Re: r5 hash detected, unable to force r5 hash

[Frederick Page]

Hi Oleg,

Oleg Drokin wrote on Sun, Apr 21 2002:

>You hit the kernel error that was fixed already.

Thank you for the info. Although super.c says:

        } else if (reiserfs_r5_hash(s) && code != R5_HASH) {
            printk("REISERFS: Error, r5 hash detected, "
                   "unable to force r5 hash\n") ;
            code = UNSET_HASH ;
        }

>Seriously, you run old kernel, went into problems, and instead of
>upgrading to recommended kernel with recommended patches you just
>wrote your original letter.

Please take a look at the original mail. As soon as I ran into
problems, I followed the advice on the home-page and upgraded to
2.4.18, it's near the bottom of my original mail. I also stated, that
nothing changed, I did not run any buggy "official" kernel, but an
Alan Cox one. I'm still very reluctant on running the official 2.4.18,
since 2.4 linux has gone Windows :-/

>I think Linux is mostly "do/figure out it yourself" thing

Yes.

>you are either able to solve your problems based on information
>located elsewhere, or just do not touch anything without consulting
>with knowledgeable person.

I do consider myself being able to solve (most of) my own problems.
But as you stated earlier: there are still some bugs in the kernel,
that interact with reiserfs.

>If you touched something you was not sure about and it broke - bah,
>bad luck.

Sure. But it did not hurt asking here, I got my data back and can now
experiment with the "tea" hash, because the partition's main purpose
is the files of the freedb (550000 little files in about 10
directories). ext2 is waaaay to slow and wastes much space (2.2 GB).

Thanks and kind regards

Frederick

Re: r5 hash detected, unable to force r5 hash

[Oleg Drokin]

Hello!

On Sun, Apr 21, 2002 at 10:13:41PM +0200, Frederick Page wrote:

> >You hit the kernel error that was fixed already.
> Thank you for the info. Although super.c says:
>         } else if (reiserfs_r5_hash(s) && code != R5_HASH) {
>             printk("REISERFS: Error, r5 hash detected, "
>                    "unable to force r5 hash\n") ;
>             code = UNSET_HASH ;
>         }

There is separate patch, that was not included into 2.4.18 for whatever reason,
but was included into 2.4.19-pre3.
So you may try 2.4.19-pre3+ kernel, or patch you kernel with patches from
2.4.18.pending subdir on our ftp site. (this is mentioned on a web site, even)

> >Seriously, you run old kernel, went into problems, and instead of
> >upgrading to recommended kernel with recommended patches you just
> >wrote your original letter.
> Please take a look at the original mail. As soon as I ran into
> problems, I followed the advice on the home-page and upgraded to
> 2.4.18, it's near the bottom of my original mail. I also stated, that

Hm. So you went only half-through the instructions, then?
If latest kernel does not work for you, try applying all the pending patches.

> nothing changed, I did not run any buggy "official" kernel, but an
> Alan Cox one. I'm still very reluctant on running the official 2.4.18,
> since 2.4 linux has gone Windows :-/

That's your sole decision. 2.4.18 works great for me.
I even had 2.4.2 with 405 days of uptime until recently ;)

Bye,
    Oleg