April 29, 201412 yr Hi, I got at home and when trying to access my unRaid server it wasn't responsive, so I checked the tower dashboard and there was a disk with DISK_DSBL status. So I started to search for answers on the forum, and tried to stop and reboot. After some tries and swapping the cables, after reboot the failed drive kept with DISK_DSBL, but a second one started to present Unformatted Disk. So, this is the first time that I got on this, so I don't know what to do. Formatting the second would lost all data stored there. Since I'm with two drive problems, I'm worried into losing data. I have another 4 drives on the array, they seems to be fine. I'm currently with the server down, so I'd like some help on what to do on these case, or is this a lost case? Thanks for any help.
April 29, 201412 yr A disk showing as 'unformatted' in unRAID normally means that unRAID failed to mount it for some reason - not that it is really unformatted. There has been a lot of discussion about having a new 'mount failed' status instead (with the 'unformatted' one remaining for when a disk is really detected as unformatted) to make it clearer, but that has not yet happened. The chance is high that the data on the drive that is showing as unformatted is intact. but that some sort of corruption has happened at the reiserfs level on the drive and that is stopping unRAID from mounting it successfully. The course of action to check this is to stop the array; start it in maintenance mode; and then from a console/telnet session run the command: reiserfsck --check /dev/md? where ? corresponds to the drive number that you are checking. The check can take some time (hours if it is large drive) so if using a telnet session make sure you do not close it while the check is running (or install 'screen' and run the check under 'screen' so the check continues running after closing a telnet session). If any potential problems are found the output from reiserfs should suggest a course of action to correct problems identified. However it is a good idea to check back here before actually taking any corrective action.
April 29, 201412 yr and then attach a full syslog: http://lime-technology.com/forum/index.php?topic=9880.0
April 30, 201412 yr Author Sorry, didn't read the post with the guideliness I'm running the latest version 5.0.5, I'm running since first versions of rc. I've already issue some problems with disk failures, but this is the first time that this kind of problem happened The unraid was running with stop array, and the disk2 is not visible. I'm attaching the most recent syslogs, since the event started to fail. Thanks Archive.zip
April 30, 201412 yr Author this is the log from today, I use split to break the log file into smaller one. today.zip
May 4, 201412 yr Author I had some issues to get the smart reports, the HD wasn't mounting properly. The disk1 is still with DISK_DSBL, and disk2 is showing as unformatted. I still didn't do any command, since I hadn't time to do it yet. smart.txt
May 7, 201412 yr Author Hi, I started to work on this problem, however I'm having some issues with drive recognition. The details about the driver are shown, when the array is stopped, but it consider as no device available for that disk. I was able to get the SMART reports, but struggling with running the reiserfsck --check /dev/md? command. I stopped the array, then put it into maintenance mode and tried to umount the /dev/md2, but it couldn't do so. So I couldn't run the reiserfsck check. If both my drive failed, what are the procedures to do, and what are the damages caused? If I consider to buy new HD to replace them, what should I do? thanks
May 7, 201412 yr Author Sorry, my bad. I read the docs but didn't read the versions. The unraid 5.0 doesn't require to umount the drives. So running on the drive that is showing Unformatted (disk2) I got this output: root@Tower:~# reiserfsck --check /dev/md2 reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/md2 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 Wed May 7 00:41:35 2014 ########### Replaying journal: Trans replayed: mountid 101, transid 86822, desc 2389, len 1, commit 2391, next trans offset 2374 Trans replayed: mountid 101, transid 86823, desc 2392, len 1, commit 2394, next trans offset 2377 Trans replayed: mountid 101, transid 86824, desc 2395, len 7, commit 2403, next trans offset 2386 Trans replayed: mountid 101, transid 86825, desc 2404, len 9, commit 2414, next trans offset 2397 Trans replayed: mountid 101, transid 86826, desc 2415, len 7, commit 2423, next trans offset 2406 Trans replayed: mountid 101, transid 86827, desc 2424, len 9, commit 2434, next trans offset 2417 Trans replayed: mountid 101, transid 86828, desc 2435, len 7, commit 2443, next trans offset 2426 Trans replayed: mountid 101, transid 86829, desc 2444, len 9, commit 2454, next trans offset 2437 Replaying journal: Done. Reiserfs journal '/dev/md2' in blocks [18..8211]: 8 transactions replayed Checking internal tree.. \/ 4 (of 10|/ 66 (of 146\/113 (of 170| The problem has occurred looks like a hardware problem. If you have bad blocks, we advise you to get a new hard drive, because once you get one bad block that the disk drive internals cannot hide from your sight,the chances of getting more are generally said to become much higher (precise statistics are unknown to us), and this disk drive is probably not expensive enough for you to you to risk your time and data on it. If you don't want to follow that follow that advice then if you have just a few bad blocks, try writing to the bad blocks and see if the drive remaps the bad blocks (that means it takes a block it has in reserve and allocates it for use for of that block number). If it cannot remap the block, use badblock option (-B) with reiserfs utils to handle this block correctly. bread: Cannot read the block (225697115): (Input/output error). Aborted (core dumped) The disk1, that shows DISK_DSBL, running the command I got: root@Tower:~# reiserfsck --check /dev/md1 reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/md1 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 Wed May 7 01:05:51 2014 ########### Replaying journal: Done. Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed The problem has occurred looks like a hardware problem. If you have bad blocks, we advise you to get a new hard drive, because once you get one bad block that the disk drive internals cannot hide from your sight,the chances of getting more are generally said to become much higher (precise statistics are unknown to us), and this disk drive is probably not expensive enough for you to you to risk your time and data on it. If you don't want to follow that follow that advice then if you have just a few bad blocks, try writing to the bad blocks and see if the drive remaps the bad blocks (that means it takes a block it has in reserve and allocates it for use for of that block number). If it cannot remap the block, use badblock option (-B) with reiserfs utils to handle this block correctly. bread: Cannot read the block (232423424): (Input/output error). Aborted (core dumped)
May 7, 201412 yr Author Oh, I forgot to mention, after running the reiserfsck --check /dev/md2 and starting the array again, it is not showing as unformatted. It seems that it was properly mounted. Are there any checks that I can run after it? Should I replace just the disk1? Thanks
Archived
This topic is now archived and is closed to further replies.