I setup my unraid last night, it went through its initial parity check (1x1TB parity, 1x1TB storage for the moment). I then instructed it to copy 930GB of material over. It worked well through the night and into the morning and in the afternoon when the drive was about half full, Windows told me that it couldn't read the file any longer and to check if the drive is still connected. If I tell it to try again, it tries to copy the file at about 500k/sec (whereas it was going along consistently at 11MB/sec all night) and fails. It doesn't matter which movie file I copy at this point, somewhere along the line Windows throws up an error (copying another file so I can get the exact text) after slowing down to a halt.

 

The server shows 0 errors and both drives are fine (I think that's green).

 

I'm using... an ASUS P5W DH Deluxe, 2x WD GP drives, 2GB of known good ddr2-533 ram, and a Celeron 430. Any ideas what could be happening? Bad sectors on disk that aren't flagged as such?

Interestingly Windows points the blame at the drive I'm copying from, yet that file works and plays perfectly and the drive I currently have the same data copied to exhibits the same failure. Going to try and rule out my drives now.

 

Edit: File copied successfully without issue from one internal drive to another. Trying to move it to UNRAID from its new location now.

 

Edit2: It's failing again, initially starts copying at about 9-10MB/sec, but before it is even 5% complete, it slows down to a halt and then states: "There is a problem accessing C:\...\Superman - The Movie.mkv. Make sure you are connected to the network and try again." Unraid control panel reports 0 errors. Guess I'll run another parity check while I wait for input...just wish it didn't take 5 hours

Please copy your syslog and post it, see my sig for the Troubleshooting link.  Do not reboot before capturing it.

Abbreviated syslog here, just did a cat on it, going to go get the full file now.

 

Full log now attached.

Awesome. After plugging the flash drive back in and booting up the server, it didn't detect either hard drive.

 

Another reboot from the web control panel and the system sees the drives again. Also, these copies were done to a disk share.

Awesome. After plugging the flash drive back in and booting up the server, it didn't detect either hard drive.

 

Another reboot from the web control panel and the system sees the drives again.

Power down, unplug from the wall outlet, and check for the obvious: a loose cable, a loose interface card (if the disk controller is not on the motherboard)

 

Is it possible one disk drive failed and is affecting the other.  Can you see the disks in the BIOS?  If not, Linux will never see them.

 

The errors in the syslog all seem to be on drive /dev/sdd

(pci-0000:00:1f.2-scsi-2:0:0:0 (sdd) ata-WDC_WD10EACS-00D6B1_WD-WCAU44009452)

You might try unplugging it. Or swapping out the cable to it.

 

Joe L.

Controller is on the motherboard, cables are brand new, never used, still gonna swap one cable out once I figure out which disk is which (disks are also brand new never used). Now to figure out which of the two drives that is...

 

Isolated the correct drive, and swapping the cables now.

Ok, cable swap is complete, problem persists.

 

I'm trying to copy the file now with the command prompt and it doesn't seem to be stopping. I'm going to try to use Robocopy so I can at least see how it is progressing.

 

-- Robocopy seems to be having the same issue. It has stopped at 1.5%. Going to let a parity check run to completion and if that doesn't fix it, RMAing the drive.

These errors in the syslog are an indication of a drive that cannot be read.  You can try "robocopy", but it will not change the fact that some hardware in your server is not working.

 

It sounds like you eliminated the SATA cable by replacing it, but it could as easily be the power cable to the drive, especially since you said none of the drives were found by the BIOS when you rebooted.

 

I would expect the unRAID management page to be showing you errors and or a red indicator adjacent to the drive in question.  It will still appear as if the array is working if you have a parity drive, but the errors in the syslog show you are running in a degraded state.

 

[pre]

Dec  3 14:48:57 library kernel: ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0

Dec  3 14:48:57 library kernel: ata3.00: irq_stat 0x40000008

Dec  3 14:48:57 library kernel: ata3.00: cmd 60/08:00:3f:00:a4/00:00:4b:00:00/40 tag 0 ncq 4096 in

Dec  3 14:48:57 library kernel:          res 41/40:00:3f:00:a4/82:00:4b:00:00/40 Emask 0x409 (media error) <F>

Dec  3 14:48:57 library kernel: ata3.00: status: { DRDY ERR }

Dec  3 14:48:57 library kernel: ata3.00: error: { UNC }

Dec  3 14:48:57 library kernel: ata3.00: configured for UDMA/133

Dec  3 14:48:57 library kernel: sd 3:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08

Dec  3 14:48:57 library kernel: sd 3:0:0:0: [sdd] Sense Key : 0x3 [current] [descriptor]

Dec  3 14:48:57 library kernel: Descriptor sense data with sense descriptors (in hex):

Dec  3 14:48:57 library kernel:        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00

Dec  3 14:48:57 library kernel:        00 a4 00 3f

Dec  3 14:48:57 library kernel: sd 3:0:0:0: [sdd] ASC=0x11 ASCQ=0x4

Dec  3 14:48:57 library kernel: end_request: I/O error, dev sdd, sector 1269039167

Dec  3 14:48:57 library kernel: ata3: EH complete

Dec  3 14:48:57 library kernel: sd 3:0:0:0: [sdd] 1953525168 512-byte hardware sectors (1000205 MB)

Dec  3 14:48:57 library kernel: sd 3:0:0:0: [sdd] Write Protect is off

Dec  3 14:48:57 library kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00

Dec  3 14:48:57 library kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Dec  3 14:48:57 library kernel: md1: read error!

Dec  3 14:48:57 library kernel: handle_stripe read error: 1269039104/1, count: 1

Dec  3 14:50:53 library kernel: ata3.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x0

Dec  3 14:50:53 library kernel: ata3.00: irq_stat 0x40000008

Dec  3 14:50:53 library kernel: ata3.00: cmd 60/08:08:3f:00:74/00:00:5b:00:00/40 tag 1 ncq 4096 in

Dec  3 14:50:53 library kernel:          res 41/40:00:3f:00:74/c6:00:5b:00:00/40 Emask 0x409 (media error) <F>

Dec  3 14:50:53 library kernel: ata3.00: status: { DRDY ERR }

Dec  3 14:50:53 library kernel: ata3.00: error: { UNC }

Dec  3 14:50:53 library kernel: ata3.00: configured for UDMA/133

[/pre]

 

 

The drives not being detected happened only the one time and I'm not sure why. Each subsequent restart was met with detected drives.

 

When I took that log, unraid showed green circles and 0 errors. Parity check is still going, albeit quite slowly at the moment, 22% complete. When it is finished, I'll try to copy to the drive again and post another log.

 

Edit: Parity check is progressing along at a blazing 250KB/sec. At this rate it will not finish by this month, here's the log.

I'm afraid those are media errors, with an error flag of UNC, which indicates 'uncorrectable'.  Looks like bad sectors on your brand new drive, and the fact that it is reporting them *may* mean that it has already run out of remapping sectors for the drive.  I would stop everything, and obtain a SMART report for the drive, and let us look at it, before you do anything else.  You may be wasting your time trying to copy to it, or parity check it.  The fact that it is moving so slow is a very bad sign too.  I suspect you will want to RMA this drive.  As Joe said, it is sdd, the WD 1TB with serial ending in 9452, which should be on the top label.

 

The reported bad sectors appear to be at about 65% of the drive.  I don't know if that corresponds to the point where you said it stopped copying, at "about half full".

 

A few other comments, less important:

 

The network connection is at 100 Mbps, not gigabit speed.

 

Consider adjusting the DHCP settings, wherever the DHCP server is.  Your server is renewing its lease every 2 hours.  Once a day or week are more common values.

 

The syslog indicates that you have a very curious SATA II device connected to the second motherboard SATA port.  It is identified as a "Config  Disk", "RGL10364", and has only 640 sectors, 320K!  It says its capacity is 0MB.  The kernel recognizes it, and says it is on the DMA blacklist, so DMA is disabled, and it is configured for PIO4 mode.  It also says it has an "unknown partition table".  Very strange...

 

 

Thanks for all the assistance. Instead of burning more time with it as I need to get to sleep, I've already filed an RMA request with Newegg and will be shipping it back to them tomorrow (A drive with even a hint of failure to me is worth replacing). 65% looks like it would be much closer to the truth than "about half" so that all sounds quite right. Network is at 100mbps just because I have it in a 10/100 switch right now (that plugs into my gigabit Airport Extreme)...I still need to move devices around but network activity at the time was not conducive to changes. I think the Airport's default is 2 hours, I'll certainly change that.

 

As for that last device, I believe it is something specific to the Asus P5W DH Deluxe. Some Google searching resulted with this info:

 

>> fdisk -l /dev/sdb

>> Disk /dev/sdb: 0 MB, 327680 bytes

>> 255 heads, 63 sectors/track, 0 cylinders

>> Units = cylinders of 16065 * 512 = 8225280 bytes

>> Disk /dev/sdb doesn't contain a valid partition table

>>

>> So it presents itself as a 320k disk, filled with zeroes as below:

>>

>> dd if=/dev/sdb |hexdump

>> 0000000 0000 0000 0000 0000 0000 0000 0000 0000

>> *

>> 0050000

>>

>> 640+0 records in

>> 640+0 records out

>> 327680 bytes (328 kB) copied, 0.0106662 seconds, 30.7 MB/s

>>

...

> Is this 320k of cache memory, or in any way some actual storage on the

> system? Have you tried to write to it out of curiosity? Seems odd that

> it would be detected if there were nothing at all present, although

> obviously it could be artifact.

 

According to the product outline at

http://www.siliconimage.com/products/product.aspx?id=64, the Silicon Image port multiplier

has an EEPROM of unspecified size.

 

With the drive appearing as precisely 320K I wouldn't be surprised if this EEPROM is what

it was seeing. Even though it's currently filled with zeros I dare not write to it

through fear of bricking the controller.

 

Greg

 

The siliconimage site has changed since that info, but maybe it is some construct of the ASUS EZ-BACKUP component of the board (though I do have that disabled right now in the BIOS). Newegg describes the board as having: 0/1/5/10 Matrix RAID, Jmicron JMB363, and Silicon Image 4723 under raid controllers, and it definitely has sata ports near the southbridge, one with an esata pair near the northbridge, and two next to the ezbackup chip. Given that the EZ-BACKUP is actually a single SATA channel yet has two ports, I'd wager that's the related chip.

 

Good night and thanks!

Got my replacement drive in a beat up box (THX UPS!). Data-rebuild is in progress...though I imagine I may just delete it all and recopy as I would rather leave no chance that the data's integrity has been compromised.