sdumas

PS - I downloaded LinuxReader and tried to access either one of these disks separately outside UnRAID. They can't be accessed - they are truly dead.

Disk5 has died... it no longer is accessible. I am now in a situation where 2 disks have died two days apart... I am screwed.

Here is a screenshot of the interface

Crap - that disk5 just failed and disappeared from the list... Now I have two drives that failed... Here is the syslog... syslog.txt

Hi everyone, I am running 5.0 Beta13 - I have been running this for ever and it was working fine until a few days ago. One of the drive went "missing". I decided to replace the drive and rebuild. So far so good. 2TB drive -the rebuild went well until about 68% (1.36TB) rebuilt. Now it is sloooooow as hell (34.45KB /sec). I notice that during the rebuild a second drive came up with LOTS of errors (475597 errors) - so I guess I have another drive that decided to go bye bye. I am not sure that I can rebuild the original drive since the other one with error seem to slow down the rebuild to an impossible timeframe (304,305 minutes remaining). Is there a way to rebuild two drives? (my thinking is no, but...) Any brilliant ideas to help me here? FWIW - I only store data on particular drives - the data is not spread across multiple drives. Thanks!

Sounds good. Thanks!

I have been running 5.0 Beta 13 for a long while with no issues. Are there any reasons for me to upgrade to the latest RC? (nonobstant of the slow write issue with 4GB). Does it have better performance? or something that I should be aware (or afraid) of? Thanks!

... I meant Parity-Check not rebuild

I was just wondering if the number of drives affect the speed of the parity build and copy process. I have a Asus P5B mobo with the SuperMicro SAS MV8 controller and 12 drives in a Norco box. My 3TB parity drive is on the mobo SATA port. I always had performance issues (or perceived performance issues) where a copy of files (even internal with NC) is never higher than 20-30MB/s. The parity build on the other end goes to 70-80 MB/s. I am not using User Share and always copy directly to the drives (\\tower\disk1...etc.). I built another machine for testing (Asus mobo and only internal drives - yes I know it's generic - too lazy to open the box and look for exact model... but it's comparable to the other one) and it has only three drives. When I build parity, I hit 110-120MB/s. When I copy files I get 30-40 MB/s. It looks to me that the amount of drives does have an effect on speed and parity build. Am I right in my assumption, or are there other parameters to take into considerations. PS - I am using 5.0 Beta-13 (works well for now and is stable...), NICs are confirmed 1 GB, no user share, 4 GB of RAM on both boxes - no apparent errors in the logs Thanks for commenting on this.

And here is a screenshot of the main monitor.

Here is the log unraidlog.txt

OK Guys and girls, I am trying to figure out performance issues on my unRAID box. Running Beta13 for a while. Had issues at some point where I lost drives (red balled) went through hell and back - system is good now. It's running on a nice Norco 4020 and has 11 drives in it - mix of onboard SATA and a 8 port SAS controller. I am getting slow speed on write on the network - 10-15 Mbps - I could undertand that - it's the network... I am using MC on a Putty connection and I copy files between drives and I still get slow speed... why??? 14 Mbps... Look at attached screenshot of MC. I'll post log in next post.

SOLVED Playing around with many variables - Disks - Controllers - Backplanes - Cables - Motherboard - Power Supply, I could eliminate most of them and it would seem that the Power Supply made the whole difference. I had a 650W (Corsair T650W) and even with the amount of drives I had (11), it would seem that switching to a 1000W PS worked out things. There are still in my mind some issues that are kinda unanswered, but overall it now works and I am happy. As an aside, I also played in the BIOS. Before, I had issues with write performance - 6 to 10 MB/sec - always banged my head on the wall on this, and finally I had the "Duh" moment. My drives were set at Compatibility Mode (IDE) - changed that to AHCI and surprisingly enough - I now get 70MB/Sec writes... Duh.

Oh thy woes and howrors... :'( I had to not touch this for a couple of days as I was thinking (again) of ways to destroy the whole thing... Time to refrain myself of doing something bad. I redid the DDRescue - forward and backward - it recovered (or so it seems) all the data minus 57 kb. Pretty good, I think. I did the reiserfsck --check /dev/sda1 - Got the "superblock cannot be found" error again. Suggested a rebuild - did the rebuild - could not rebuild - suggested rebuild-tree, did the rebuild-tree. That took a while (8 hours) ... (don't have the beginning of this log) ######## Pass 1 ######## Looking for allocable blocks . . Finished Flushing .. finished 0 leaves read 0 inserted ######## Pass 2 ######## Flushing .. finished No reiserfs metadata found . If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you had used one. Then you probably rebuilt the superblock as there was no one. Zero the block of 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfsck /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version Aborted ... Now what? - I am a little lost and discouraged. The data is not that important (it's more inconvenient than anything) but I would love to find a way to recuperate it. Because if this happened on another drive that was critical - I would be in big trouble. I still have the original "bad drive", I can DDrescue again if need be... Thanks for all the help so far!!!!!!

Thanks will do - that will take a while - It will be probably another 6 hours to complete the first pass. I'll start the reverse retry later on tonight! Thanks again!

The rebuild-tree failed - I did not have much hope anyway on this one. I am redoing the DDrescue "ddrescue -f -n /dev/sda /dev/sdb logfile2" (the drives are inverted on this pass) and when this part is finished, I will perform the reverse with 3 retry. I'll have then a "brand new disk" with the hopefully recoverable data on it. I'll wait for this to finish and then review the next steps before I proceed.

Thanks guys!!!! - Good catch ... sda vs sda1... ouch. Weebotech - During the rebuild-sb, it tried to bebuild the tree and it failed. So I did not try running rebuild-tree separately. I am running it now - it looks like this can take a while... I'll let it run and then if this does not work - go back to square one since I do have the original "bad" disk. I will re-run another DDrescue on it and start from there.

I do have the rebuild-sb log after all: root@Tower:/boot# reiserfsck --rebuild-sb /dev/sda reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes reiserfs_open: the reiserfs superblock cannot be found on /dev/sda. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, ch oose this one) (3) < 3.5.9 converted to new format (don't choose if unsure) (4) < 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: No journal device was specified. (If journal is not available, re-run with --no- journal-available option specified). Is journal default? (y/n)[y]: Did you use resizer(y/n)[n]: rebuild-sb: no uuid found, a new uuid was generated (a1dbf596-df91-4182-afc7-0ba 0719ea20f) rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: y Reiserfs super block in block 16 on 0x800 of format 3.6 with standard journal Count of blocks on the device: 488378640 Number of bitmaps: 14905 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: a1dbf596-df91-4182-afc7-0ba0719ea20f LABEL: Set flags in SB: Mount count: 1 Maximum mount count: 30 Last fsck run: Wed Dec 7 19:02:35 2011 Check interval in days: 180 Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. and here is the reiserfsck log root@Tower:/boot# reiserfsck --check /dev/sda reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/sda 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 Dec 7 19:08:39 2011 ########### Replaying journal: No transactions found Zero bit found in on-disk bitmap after the last valid bit. Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted By the way - all of this was done on the "rebuilt" disk done with DDrescue.

I am trying to recuperate data from what looked like a dead disk, but may be not (dead that is). The drive was giving me the DRDY error message and was kind of looping at boot. After a few tries, it finally came up. I setup a separate server to perform the recuperation. I used the ddrescue procedure enumerated in this forum. It seems to have recuperated 1TB of data minus 64kb. After a few hours this log file was created: # Rescue Logfile. Created by GNU ddrescue version 1.14 # Command line: ddrescue -f -n /dev/sdb /dev/sda logfile1 # current_pos current_status 0x00018E00 + # pos size status 0x00000000 0x00018000 + 0x00018000 0x00000E00 / 0x00018E00 0x00000200 - 0x00019000 0x01061000 + 0x0107A000 0x00000E00 / 0x0107AE00 0x00000200 - 0x0107B000 0xE8DFD3B000 + I had only 64k of errors at the beginning of the disk in two errors. I was getting kind of excited and I rebooted the box minus the failed disk. My new drive was showing unformatted... hum. Ran a reiserfsck and got this: "reiserfs_open: the reiserfs superblock cannot be found on /dev/sda. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb." Before doing this I decided to use the "unraid_partition_disk.sh -A -p /dev/sda" command. This is the result: ######################################################################## Device Model: ST2000DM001-9YN164 Serial Number: Z1E02X9S Firmware Version: CC96 User Capacity: 2,000,398,934,016 bytes Disk /dev/sda: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 64 3907029167 1953514552 83 Linux Partition 1 does not end on cylinder boundary. ######################################################################## ============================================================================ == == DISK /dev/sda IS partitioned for unRAID properly == expected start = 64, actual start = 64 == expected size = 3907029104, actual size = 3907029104 == ============================================================================ Reran reiserfsck --check and still could not find the superblock. Decided to run the rebuild-sb (don't have the output of this one) but I got a message that the rebuild-tree failed. Any ideas? Any other logs or procedures I could try? Thanks!

I have two of these controllers. I'll switch them to see if it makes a difference.

"Where the drives by the same manufacturer? bought at the same time? how old where they?" Nope - different drives, bought at different times - some Seagates - some WD - black, blue and greens. Changed a few over the years - so four in a row sounds highly improbable. See the new thread I started: http://lime-technology.com/forum/index.php?topic=16968.0

Screenshot

It's been over 8 days that I am trying to figure this out and bring my array into a somewhat better state. If you want to read the details of what I have done so far you can check it here: http://lime-technology.com/forum/index.php?topic=16859.0 This is a quick summary: I upgraded my standard PC case about three months ago to a Norco 4220. Everything seemed to be running fine until one day I had a drive that red balled. I got another drive and like usual put the drive in and let the machine rebuild the drive. Except that this time it did not work. Not only did it not rebuild the drive but on boot up another one failed as well, and then parity did the same. Too many drives in too little time to be "real" hard drive failures. Looked up the case - verify connectors - backplane - drives in the box and outside the box - did stupid things (rebuild-sb) - and I ended up loosing one drive of data. After a long tedious process - I got my main drives up and running (changed motherboard from Asus P5K-E to a Gigabyte GA-Z68XP-UD3 - upgraded to Beta 14 (onboard SATA controller not recognized by 4.7 - then downgraded to Beta 13 when I suspected other issues) Now I have an unprotected array that works. But it's unprotected. I precleared a new parity drive and installed it in the box. Parity is extremely slow to rebuild (89000+ minutes) and errors now on another drive; ata3- (highly unlikely). I can't have lost 4 drives in the matter of a week. Different brands - different sizes... Running 5.0 Beta 13 Pro - Gigabyte GA-Z68XP-UD3 - i3 processor - 4 GB of RAM - 8 onboard SATA ports - 6 usable (2 onboard controllers 1-Intel Z68 Sata, 2-Marvel 88SE9172) - SuperMicro AOC-SASLP-MV8 and a Sil3132 2 ports SATA controller (PCIe 1x) I unnassigned the parity drive and I am still getting errors on ata3. Here is my latest logs - screenshot of the main menu on following post unraidbeta13lognov302011.zip

I am starting to see a pattern here... It seems to be a recurring occurence. You're the third person that has a similar problem. Did you have issues before this happens? I had several disk related issues. But if I believe the logs - for me - it would be my fourth disk out of ten that failed... highly improbable... I have a parity check right now that is running so slow it should take over two months to complete - I guess I'll have to live without parity until someone figures this out. I have enjoyed my unRAID for a few years now without issues and then suddenly - 4 disks within days of each other that failed - ... I don't think so.

Here is a screenshot of my main menu - now at 69000+ minutes....