August 3, 201510 yr So after experiencing a slow parity rebuild during a time where I was upgrading the parity drive it turns out I have a drive that is probably going bad. SMART info doesn't show anything particularly wrong with the drive, but Unraid won't mount the drive. When I tried to do a reiserfsck it suggests using the rebuild-sb as a file system is not being seen. Can anyone assist in the proper way to attempt recovering of the file system on this drive? I have no parity at this time so I would like to attempt to recover this data. Every drive in this system is reiser as I know none had been converted to the new default of XFS.
August 3, 201510 yr Author I've seen that but I see the following notes reiserfsck --rebuild-sb /dev/md3 -> rebuilds superblock based on series of questions, answers MUST be accurate! Is there a list of proper questions/answers or does it default to all the proper answers?
August 3, 201510 yr Community Expert I've seen that but I see the following notes reiserfsck --rebuild-sb /dev/md3 -> rebuilds superblock based on series of questions, answers MUST be accurate! Is there a list of proper questions/answers or does it default to all the proper answers? Are you sure the disk is in ReiserFS format? If it is XFS (which is now the default for v6) theN reiserfsck is not the correct tool to use.
August 5, 201510 yr Sorry, I had forgotten to add the questions and answers to that wiki page. Somewhere (probably for v4 unRAID's) is a link to an old post with the correct answers, but if you search, there's a recent post indicating Tom's recommendations. I assume they are the same, but need to check that. Try searching rebuild-sb, and select 'order by recent' posts.
August 6, 201510 yr Author Ok, well I decided to move this drive to another unraid system, and while the GUI still showed unmountable/unknown file system, I was able to manually mount the drive, perform a reiserfsck, and then browse through some of the folders on this drive. I then placed the drive back in my primary unraid server and it still shows as unmountable I then did mount /dev/sdq1 /mnt/t and once again can see folders on this drive. Any ideas?
August 6, 201510 yr Have you ran a reiserfck --check /dev/md(drive letter) on it? If so, did it suggest that you run with rebuild-tree?
August 6, 201510 yr Community Expert Ok, well I decided to move this drive to another unraid system, and while the GUI still showed unmountable/unknown file system, I was able to manually mount the drive, perform a reiserfsck, and then browse through some of the folders on this drive. I then placed the drive back in my primary unraid server and it still shows as unmountable I then did mount /dev/sdq1 /mnt/t and once again can see folders on this drive. Any ideas? Has the disk been red-balled in the primary server? If so then unRAID will have stopped using the physical disk and the one that is being marked as unmountable is the 'emulated' disk using the combination of the other drives plus parity. This might explain what you are seeing?
August 6, 201510 yr Author That's it, I see now where it has the Red-X and states drive is being emulated. I do not have a proper Parity in place at this point so whats the proper way to just ignore the parity/emulated setup?
August 6, 201510 yr Community Expert That's it, I see now where it has the Red-X and states drive is being emulated. I do not have a proper Parity in place at this point so whats the proper way to just ignore the parity/emulated setup? Tools - New Config
August 6, 201510 yr Community Expert That's it, I see now where it has the Red-X and states drive is being emulated. I do not have a proper Parity in place at this point so whats the proper way to just ignore the parity/emulated setup? What exactly do you mean by "I do not have proper Parity in place"? It can't emulate a drive without parity.
August 6, 201510 yr What exactly do you mean by "I do not have proper Parity in place"? It can't emulate a drive without parity. From a few posts back - the data disk was modified on another system, so the data drive and the parity drive are out of sync. So, the options are to either discard the parity and trust the repaired data drive or to try to repair the emulated drive and rebuild the data drive.
August 13, 201510 yr Author Ok, So I'm a little concerned as to what initiated these problems but here are the end results. After forcing the drive that was showing unformatted back into the array I did the following. I Ran a SMART Extended test on every drive, every drive came back healthy, no new reallocated sectors... etc. I then ran reiserfsck on each drive. Two of my drives, disk9 and disk11 reported needing to run the --rebuild-tree option. I then manually backed up the data off these two disk, I believe disk9 had maybe 10 files that it reported it was unable to copy, all others seemed to backup. I then ran the rebuild-tree option, it performed some repairs. I followed it up by running a regular check again. At this point I was then confident that all file systems were healthy. Last step was to allow the parity to build, previously this would come to a stand still and never complete, I am guessing because of the corrupted files. This time parity rebuilt without issue. Original goal when I started this ordeal was to go from a 4tb to 6tb parity drive. It seems this upgrade uncovered some issues. With the SMART test passing though I am not fully convinced I should blame the hardware of disk9 and disk11 so I may just keep a close eye on things and plan to do some file system checks again in the near future some time.
August 13, 201510 yr Community Expert Last step was to allow the parity to build, previously this would come to a stand still and never complete, I am guessing because of the corrupted files. This time parity rebuilt without issue. File system corruption should not really affect a parity run as the parity process is not aware of file systems. However all is well that ends well.
August 13, 201510 yr Author Last step was to allow the parity to build, previously this would come to a stand still and never complete, I am guessing because of the corrupted files. This time parity rebuilt without issue. File system corruption should not really affect a parity run as the parity process is not aware of file systems. However all is well that ends well. Well there goes that theory then. Strange, will be keeping a closer eye on SMART Checks and file system checks moving forward.
Archived
This topic is now archived and is closed to further replies.