After having run reiserfsck --rebuild-sb and then reiserfsck --fix-fixable the resulting partition is not mountable. Further reiserfsck --check do not show any issue; BUT, after modifying the hash function id from '00' to '03' in the superblock, as explained in the specified URL (NOTE: 1 year old!!!), everything works as should. The superblock can usually be found at block #16, so the hexadecimal edit is pretty trivial for a techie but a dead-end for a noob. *This one should be fixed, and propagated to other distros too*
Procedure to rebuild the superblock of a corrupted reiserfs partition (ReiserFS 3.6 in my case): 1) reiserfs --rebuild-sb /dev/hda3 2) reiserfs --fix-fixable /dev/hda3 3) mount /dev/hda3 # fails and gives the following error ReiserFS: hda3: vs-7000: search_by_entry_key: search_by_key returned item position == 0 4) hexdump -C -s 65536 -n 512 /dev/hda3 # this is the superblock 00010030 06 00 01 00 52 65 49 73 45 72 32 46 73 00 00 00 |....ReIsEr2Fs...| 00010040 00 00 00 00 05 00 c6 04 02 00 00 00 89 28 00 00 |................| After the magic '52 65 49 73 45 72 32 46 73' there is a 32bit buffer which holds 0 (big endian), this is the function hash id 5) change the function hash id to 3 (which is r5 function hash) and the partition can be mounted and works 100% ok Steps 4 and 5 are obviously necessary due to the bug
you most likely wont get any help here ... the reiserfs mailing list is the place to go, so once they have a good fix, we can merge it
Is reiserfs development active? How long is it since they last updated the product? The cited mailing list message is more than 1 year old...if they haven't fixed in 2006, I wonder if they will later Btw, it's a trivial fix - and without it reiserfs superblock rebuilding is not reliable. I would propose to explicitly say in our official docs that data recovery of ReiserFS partitions is not 100% guaranteed and that paid support is available by Namesys only; otherwise a newbie does not really get the difference against other filesystems. Filesystem reliability in case of data recovering is very important
what pray tell is this "trivial fix" ? i dont see any fix in your comments
Sorry I only explained the bug logic, the diff patch is available at the end (the subsequent page, actually) of the mailing list thread pointed by the associated URL: http://www.mail-archive.com/reiserfs-list@namesys.com/msg22149.html I will now attach it here. NOTE: I have not tested it, but it looks like correct
Created attachment 130989 [details, diff] patch for reiserfsck bug when rebuilding superblock
A workaround to this bug is to mount the device (after the biased repair) as follows: $ mount -o hash=r5 /dev/hda3 "r5" is the commonly used hashing function; the patch is consistent as it allows the correct hashing function to be set I no more claim high severity for this bug - but the annoyance remains and should be documented Regards
That is a patch against the kernel, NOT reiserfsprogs. I cannot reproduce this problem at all with 2.6.32 and reiserfsprogs-3.6.19. The hash dword remains as 0x3 correctly. Closing as upstream, as it was fixed in a different manner at some point (the kernel patch is not present, but the reiserfsck itself has changed).
