I have a disk that after a reboot just unmounted and could not remount. It says that I need to run Check Filesystem Status since it is a Reiserf disk. I did the "Check" and it came up with the following:

 

reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/md3
Will put log info to 'stdout'

reiserfs_open: the reiserfs superblock cannot be found on /dev/md3.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

 

I ran a check with the --rebuild-sb but it then asked this:

 

reiserfsck 3.6.24

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

reiserfs_open: the reiserfs superblock cannot be found on /dev/md3.

rebuild_sb: wrong version

what the version of ReiserFS do you use[1-4]
    (1)   3.6.x
    (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one)
    (3) < 3.5.9 converted to new format (don't choose if unsure)
    (4) < 3.5.9 (this is very old format, don't choose if unsure)
    (X)   exit

 

Here is where I am stuck I chose "1" but it just goes back to instructions again. How to I get it to complete the rebuild? I put diag too on this post just in case I am missing something. Everything has been working great up until reboot. Been getting a IRQ 19 error but not sure what is causing that.

 

Thanks

diagnostics-20171101-0922.zip

If you're sure it's reiser then follow this:

 

https://wiki.lime-technology.com/Check_Disk_Filesystems#Rebuilding_the_superblock

Yeah I am sure it's reiser, thanks

Well ran the  --rebuild-sb following the instructions above from Johnnie.Black but no joy it did the SuperBlock without an issue but once I ran --check again it still had some issues with the disk. The disk is /dev/sdd is coming up each time as unmountable, now I really hate to lose the data so is it possible to replace disk and the parity puts it back on? Never had to replace a drive yet.

 

I do have two other issues:

 

Call Traces found on your server

and

irq 19: nobody cared found on your server

 

I updated the BIOS like some said to fix "irq" error but not joy there.  Just got the Call Traces in the last 6 months.

 

Any help would be great.

 

I attached another copy of diag after I ran the " reiserfsck  --rebuild-sb"

 

diagnostics-20171102-0028.zip

Post the current output of reiserfsck -check, after --rebuild-sb you usually need to run --rebuild-tree.

 

The call trace is because irq19 got disable, it's usb related, so nothing to do with the disk and usually not serious unless you have usb issues.

Edited November 2, 20178 yr by johnnie.black

Humm don't have anything on the USB but keyboard and mouse that is strange. Anyway it told me to do a -rebuild-tree after it so I ran that. It did the rebuild tree all the way but came out saying "no reiserfsck metadata found"

 

Now a newb at most of this how to I get the output? I had to run all this from terminal since it would not work on the GUI part of UnRAID.

10 minutes ago, gsd2012 said:

Now a newb at most of this how to I get the output?

 

Use putty to SSH into the server, then copy/paste

Below is what came out..

 

 

_________________________________________________________

root@MistyMtnMedia:~# reiserfsck --rebuild-sb /dev/sdd
reiserfsck 3.6.24

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
rebuild-sb: wrong tree height occured (65535), zeroed
Reiserfs super block in block 16 on 0x830 of format 3.6 with standard journal
Count of blocks on the device: 488378640
Number of bitmaps: 14905
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 488378640
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: "r5"
Objectid map size 2, max 972
Journal parameters:
        Device [0x0]
        Magic [0x0]
        Size 8193 blocks (including 1 for journal header) (first block 18)
        Max transaction length 1024 blocks
        Max batch size 900 blocks
        Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0xfa03:
        FATAL corruptions exist.
         some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: 7852e86a-3d79-4824-8b98-3a914f9be916
LABEL:
Set flags in SB:
Mount count: 1
Maximum mount count: 30
Last fsck run: Wed Nov  1 12:33:02 2017
Check interval in days: 180
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@MistyMtnMedia:~# reiserfsck --check
Usage: reiserfsck [mode] [options]  device

Modes:
  --check                       consistency checking (default)
  --fix-fixable                 fix corruptions which can be fixed without
                                --rebuild-tree
  --rebuild-sb                  super block checking and rebuilding if needed
                                (may require --rebuild-tree afterwards)
  --rebuild-tree                force fsck to rebuild filesystem from scratch
                                (takes a long time)
  --clean-attributes            clean garbage in reserved fields in StatDatas
Options:
  -j | --journal device         specify journal if relocated
  -B | --badblocks file         file with list of all bad blocks on the fs
  -l | --logfile file           make fsck to complain to specifed file
  -n | --nolog                  make fsck to not complain
  -z | --adjust-size            fix file sizes to real size
  -q | --quiet                  no speed info
  -y | --yes                    no confirmations
  -f | --force          force checking even if the file system is marked clean
  -V                            prints version and exits
  -a and -p                     some light-weight auto checks for bootup
  -r                    ignored
Expert options:
  --no-journal-available        do not open nor replay journal
  -S | --scan-whole-partition   build tree of all blocks of the device

root@MistyMtnMedia:~# reiserfsck --check /dev/sdd
reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/sdd
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 Thu Nov  2 12:53:50 2017
###########
Replaying journal: No transactions found
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

Aborted

 

5 minutes ago, gsd2012 said:

(--rebuild-tree did not complete)

 

If this is the last one you need to run reiserfsck --rebuild-tree

 

 

Yep running that now it takes a while and I will post output.

Here is what happen when I ran "rebuild-tree"

 

MistyMtnMedia:~# reiserfsck --rebuild-tree /dev/sdd
reiserfsck 3.6.24

*************************************************************
** Do not  run  the  program  with  --rebuild-tree  unless **
** something is broken and MAKE A BACKUP  before using it. **
** If you have bad sectors on a drive  it is usually a bad **
** idea to continue using it. Then you probably should get **
** a working hard drive, copy the file system from the bad **
** drive  to the good one -- dd_rescue is  a good tool for **
** that -- and only then run this program.                 **
*************************************************************

Will rebuild the filesystem (/dev/sdd) tree
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal: No transactions found
###########
reiserfsck --rebuild-tree started at Thu Nov  2 14:14:33 2017
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 23115 blocks marked used
Skipping 23115 blocks (super block, journal, bitmaps) 0 blocks will be read

Could not find a hash in use. Using "r5"
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 0
                Leaves among those 0
                Objectids found 2

Pass 1 (will try to insert 0 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished

Flushing..finished
        0 leaves read
                0 inserted
####### Pass 2 #######
Flushing..finished

No reiserfs metadata found.  If you are sure that you had the reiserfs
on this partition,  then the start  of the partition  might be changed
or all data were wiped out. The start of the partition may get changed
by a partitioner  if you have used one.  Then you probably rebuilt the
superblock as there was no one.  Zero the block at 64K offset from the
start of the partition (a new super block you have just built) and try
to move the start of the partition a few cylinders aside  and check if
debugreiserfs /dev/xxx detects a reiserfs super block. If it does this
is likely to be the right super block version.

Aborted

 

/dev/sdd

 

So only noticed now, why are you running reiserfsck on the device instead of starting the array in maintenance mode and running it on the mdX device?

 

This will make your parity invalid, and worst than that you need to use the partition number, in this case:

 

 reiserfsck /dev/sdd1

 

 

 

 

I am in maintenance mode now and it stated that if the drive is file system type "reiserf" then run the "reiserfsck --check" and follow what it instructs. So should I just run it as you posted above? I was following the instructions on the post you sent me.

 

9 minutes ago, gsd2012 said:

I was following the instructions on the post you sent me.

 

No you weren't, from the wiki I linked:

 

Quote

The example below uses Disk 6 (/dev/md6), so you need to change that to the correct drive symbol for your drive.

 

 

 

9 minutes ago, gsd2012 said:

I am in maintenance mode now and it stated that if the drive is file system type "reiserf" then run the "reiserfsck --check" and follow what it instructs.

 

Yes

And in the end you 'll need to do a parity check.

Oh ok I was a bit confused on the /dev/md6 part so in my case it is drive 3 so /dev/md3 then. Can I run it all again without issue?

Just now, gsd2012 said:

Can I run it all again without issue?

 

It should still be OK, first run:

 

reiserfsck /dev/md3 

If you get invalid superblock you need to rebuild it again, if you get "Bad root block 0. (--rebuild-tree did not complete)" run with --rebuild-tree.

 

Thanks you so much I will will run it now.

Ok ran the rebuild-tree which took forever but too big to copy and paste so I am attaching it. I think the drive is fubared.

 

 

Rebuild-Tree_Output.txt

Doesn't look good, did you have to rebuild the superblock again when using /dev/md3?

Yeah did that with the right stuff and it said it worked but then during the rebuild tree it had all those errors... I am thinking the drive died. Now I hope to switch it out and the data would be recreated from parity but not much faith on that. First time I have lost a drive so far.