September 20, 201510 yr 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
September 20, 201510 yr 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.
September 20, 201510 yr Author 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?
September 20, 201510 yr 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.
September 20, 201510 yr Author 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?
September 20, 201510 yr 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.
September 20, 201510 yr 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.
September 21, 201510 yr Author Ok...so I did the --rebuild-tree. It generated the lost+found directories. What do I do next? Is there a guide linked anywhere?
September 21, 201510 yr Run with check again to confirm success. You may want to run "new permissions" to make the lost and found share accessible.
September 21, 201510 yr Author 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.
September 25, 201510 yr Author 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 ###########
October 7, 201510 yr Author 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?
October 8, 201510 yr 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.
Archived
This topic is now archived and is closed to further replies.