jaj08 Posted August 3, 2015 Share Posted August 3, 2015 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. Link to comment
jaj08 Posted August 3, 2015 Author Share Posted August 3, 2015 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? Link to comment
itimpi Posted August 3, 2015 Share Posted August 3, 2015 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. Link to comment
jaj08 Posted August 3, 2015 Author Share Posted August 3, 2015 I am sure, system was upgraded to 6, but all drives remain reiser. Link to comment
RobJ Posted August 5, 2015 Share Posted August 5, 2015 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. Link to comment
jaj08 Posted August 6, 2015 Author Share Posted August 6, 2015 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? Link to comment
gshipley Posted August 6, 2015 Share Posted August 6, 2015 Have you ran a reiserfck --check /dev/md(drive letter) on it? If so, did it suggest that you run with rebuild-tree? Link to comment
itimpi Posted August 6, 2015 Share Posted August 6, 2015 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? Link to comment
jaj08 Posted August 6, 2015 Author Share Posted August 6, 2015 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? Link to comment
trurl Posted August 6, 2015 Share Posted August 6, 2015 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 Link to comment
trurl Posted August 6, 2015 Share Posted August 6, 2015 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. Link to comment
gubbgnutten Posted August 6, 2015 Share Posted August 6, 2015 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. Link to comment
jaj08 Posted August 13, 2015 Author Share Posted August 13, 2015 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. Link to comment
itimpi Posted August 13, 2015 Share Posted August 13, 2015 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. Link to comment
jaj08 Posted August 13, 2015 Author Share Posted August 13, 2015 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. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.