[SOLVED] Bad root block...what now?

[denzo]

Had a drive fail so I replaced it with another and after rebuilding it is showing as unformatted, I repeated this with another (brand new this time) drive but I get the same thing. I have been scouring the forum for what to do and I have found several suggestions...most importantly NOT to format the drive. I ran a check on the drive and this is the result: root@UNRAID:~# reiserfsck --check /dev/sdq1 reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/sdq1

Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Tue Sep 20 05:52:12 2016 ########### Replaying journal: Done. Reiserfs journal '/dev/sdq1' in blocks [18..8211]: 0 transactions replayed Zero bit found in on-disk bitmap after the last valid bit. Checking internal tree.. Bad root block 1038754914. (--rebuild-tree did not complete) Aborted (core dumped) ___________________________________ Any ideas/suggestions? syslog too big to attach download here

[JorgeB]

You need to run reiserfsck --rebuild-tree, but don't use the sd* identifier or you'll invalidate parity, use the md* device, e.g., for disk1:

 

reiserfsck --rebuild-tree /dev/md1

[denzo]

Thanks for the super quick reply! I am running your suggestion now, looks like it will take 8+ hours. (I will report back later).

[denzo]

It has finished running reiserfsck --rebuild-tree. Here are the stats it showed at the end:

 

Objects without names 20079

Empty lost dirs removed 11955

Dirs linked to /lost+found: 2372

Dirs without stat data found 16

Files linked to /lost+found 17707

Objects having used objectids: 359

files fixed 282

dirs fixed 77

 

In my excitement I stopped the array (it was in Maintenance mode) and started the array back up. The disk is showing a green ball and I have a new share named "lost+found" Is there a "next step" to this process?

[JorgeB]

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_ReiserFS_using_unRAID_v5_or_later

 

If you were instructed to use special parameters such as --fix-fixable and --rebuild-tree, then it is possible that some files were not completely recovered. Check for a lost+found folder on this drive, which may contain fragments of the unrecoverable files. It is unfortunately up to you to examine these and determine what files they are from, and act accordingly. Hopefully, you have another copy of each file. When you are finished examining them and saving what you can, then delete the fragments and remove the lost+found folder. Dealing with this folder does not have to be done immediately. This is similar to running chkdsk or scandisk within Windows, and finding lost clusters, and dealing with files named File0000.chk or similar. You may find one user's story very helpful, plus his later tale of the problems of sifting through the recovered files.