MD5 won't mount

[Fuggin]

Hello...MD5 won't mount all of the sudden. I put in a new HDD and it does the same thing. Advice?

 

Log attached

tower-syslog-20150920-1452.zip

[itimpi]

Hello...MD5 won't mount all of the sudden. I put in a new HDD and it does the same thing. Advice?

 

Log attached

The syslog suggests that there is file system level corruption on that disk.    To prove this you need to put the array into maintenance mode and then run reiserfsck to fix this.  From a console/telnet session this would involve running a command of the form:

reiserfsck --check /dev/md5

  The expectation is that this will detect the corruption and suggest the recovery action to be taken.  It may be a good idea to check back here before doing that just as a check.

 

[Fuggin]

I thought about that, but why would it do that with a brand new HDD?

 

If I put the original HDD back in and do a fsck will I lose the data on it?

[itimpi]

I thought about that, but why would it do that with a brand new HDD?

If you started from scratch then this should not happen.

 

However if you rebuilt onto it then a rebuild does not clear file system corruption - it replicates what was there before the rebuild.

 

If I put the original HDD back in and do a fsck will I lose the data on it?

If you did a rebuild it should not matter if you use the original or the new one.  The reiserfsck normally recovers all the vast majority of the data on the disk.  If the corruption is minor this will be all the data, but if there is major corruption this cannot be guaranteed.  However reiserfsck has an incredibly good record on recovering data even after major corruption - much better than the equivalent tools for XFS and BTRFS.

[Fuggin]

reiserfsck 3.6.24

 

Will read-only check consistency of the filesystem on /dev/md5

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 Sun Sep 20 15:26:49 2015

###########

Replaying journal: Done.

Reiserfs journal '/dev/md5' in blocks [18..8211]: 0 transactions replayed

Zero bit found in on-disk bitmap after the last valid bit.

Checking internal tree..  block 462933172: The level of the node (30742) is not correct, (4) expected

the problem in the internal node occured (462933172), whole subtree is skipped

finished

Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.

Bad nodes were found, Semantic pass skipped

1 found corruptions can be fixed only when running with --rebuild-tree

###########

reiserfsck finished at Sun Sep 20 15:30:17 2015

###########

 

So...do I do reiserfsck --rebuild-tree /dev/md5 now?

 

or can I try --fix-fixable?

 

[dgaschk]

Run with rebuild tree. Always follow the instruction given by reiserfsck. I can think of no circumstances when the advise given by a file recovery program should be ignored.

[itimpi]

Run with rebuild tree. Always follow the instruction given by reiserfsck. I can think of no circumstances when the advise given by a file recovery program should be ignored.

The main reason for checking back is to catch those cases where a rebuild of the superblock is the recommended action!  Those cases nearly always mean the user specified the wrong device name.

[Fuggin]

Ok...so I did the --rebuild-tree. It generated the lost+found directories. What do I do next? Is there a guide linked anywhere?

[dgaschk]

Run with check again to confirm success. You may want to run "new permissions" to make the lost and found share accessible.

[Fuggin]

Run with check again to confirm success. You may want to run "new permissions" to make the lost and found share accessible.

 

If you could elaborate on the "check" amd "new permissions", I would appreciate it. I am new to troubleshooting this sort of thing.

 

MD5 lost over 2TB of data even after the rebuild.

 

I don't know if you mean run the Parity "check" via unraid, or a reiserfsck "check". I am worried that because MD5 lost all that data, I don't know if the unraid parity check will try to restore the missing data or just update the parity image with the new MD5 rebuild.

 

Thanks.

[Fuggin]

Bump.

 

Anyone? Just trying to wrap this thread up.

[dgaschk]

Run reiserfsck -check again.

reiserfsck --check /dev/md5

[Fuggin]

reiserfsck 3.6.24

 

Will read-only check consistency of the filesystem on /dev/md5

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 Sep 24 08:43:12 2015

###########

Replaying journal: Done.

Reiserfs journal '/dev/md5' in blocks [18..8211]: 0 transactions replayed

Checking internal tree..  finished

Comparing bitmaps..finished

Checking Semantic tree:

finished

No corruptions found

There are on the filesystem:

        Leaves 45533

        Internal nodes 282

        Directories 228

        Other files 958

        Data block pointers 45962901 (29 of them are zero)

        Safe links 0

###########

reiserfsck finished at Thu Sep 24 08:48:04 2015

###########

[Fuggin]

bumping as this hasn't been resolved in my case.

 

All the files from reiserfsck were sent to lost+found. There were still files missing.

 

Couldn't I just replace the affected HDD with another and larger HDD and the contents be replaced with the parity drive?

[itimpi]

bumping as this hasn't been resolved in my case.

 

All the files from reiserfsck were sent to lost+found. There were still files missing.

Unfortunately that means that it probably means that the file system corruption was bad.

 

Couldn't I just replace the affected HDD with another and larger HDD and the contents be replaced with the parity drive?

No - that is not how parity works. Parity is not file system aware and just recovers sectors that were not written due a disk being disabled.  It does not recover from a corrupt file system.  If you put in a new drive it would be restored to be exactly the same as the md5 you have just recovered.