foo_fighter

Yes, you can use md5deep to create and check md5 checksums on the server itself. Would it work to create checksums on the original files/directories, then copy the .hash files to the server and verify the checksums on the server? It seems to me that should work. I agree, creating the checksums before hand would be best. Sure, that would work. You'd need to change the configuration file with the checksum utility so it puts all the checksums in a single file at the root -- otherwise it will put the checksum file for each folder in that folder, which would be a lot of copying for you. I prefer the latter (so I can easily test any specific folder), but for what you want to do it would be much easier to have a single checksum file you could copy; then do the "verify checksums" command on the array. garycase: I'm actually posting this based on your comments in this thread (http://lime-technology.com/forum/index.php?topic=29514.0;topicseen) but figured it would be less of a thread-jack if I posted here. Anyway my questions are: Using the checksum windows program pointed at unraid, doesn't the program have to pull the entire file over before it can create the checksum? Given that, won't it take a veeerrrrry long time vice creating the checksums natively on the server the first time it is run? Which of course brings me to my main question: is it possible to create the checksums directly on unraid the first time in such a way that the windows checksum app will be able to take over ongoing checksum creation and validation? I just have this image of my PC and Array running full bore for days hammering my network trying to transfer all my files

Actually spoke too soon! It went through the read stage of preclear fine ~130-150MB/s but when it got to the write stage it went crazy. It's bizarre. I guess it's back to being a bad sata channel on the MB: Sep 30 04:40:01 Tower syslogd 1.4.1: restart. Sep 30 04:40:02 Tower kernel: ata4.00: configured for UDMA/133 Sep 30 04:40:02 Tower kernel: ata4.01: configured for UDMA/33 Sep 30 04:40:02 Tower kernel: ata4: EH complete Sep 30 04:40:02 Tower kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Sep 30 04:40:02 Tower kernel: ata4.01: BMDMA stat 0x66 Sep 30 04:40:02 Tower kernel: ata4.01: failed command: WRITE DMA EXT Sep 30 04:40:02 Tower kernel: ata4.01: cmd 35/00:00:00:68:6b/00:04:00:00:00/f0 tag 0 dma 524288 out Sep 30 04:40:02 Tower kernel: res 51/84:d1:2f:68:6b/84:03:00:00:00/f0 Emask 0x30 (host bus error) Sep 30 04:40:02 Tower kernel: ata4.01: status: { DRDY ERR } Sep 30 04:40:02 Tower kernel: ata4.01: error: { ICRC ABRT } Sep 30 04:40:02 Tower kernel: ata4: soft resetting link Sep 30 04:40:02 Tower kernel: ata4.00: configured for UDMA/133 Sep 30 04:40:02 Tower kernel: ata4.01: configured for UDMA/33 Sep 30 04:40:02 Tower kernel: ata4: EH complete Sep 30 04:40:02 Tower kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Sep 30 04:40:02 Tower kernel: ata4.01: BMDMA stat 0x66 Sep 30 04:40:02 Tower kernel: ata4.01: failed command: WRITE DMA EXT Sep 30 04:40:02 Tower kernel: ata4.01: cmd 35/00:00:00:68:6b/00:04:00:00:00/f0 tag 0 dma 524288 out Sep 30 04:40:02 Tower kernel: res 51/84:e1:1f:68:6b/84:03:00:00:00/f0 Emask 0x30 (host bus error) Sep 30 04:40:02 Tower kernel: ata4.01: status: { DRDY ERR } Sep 30 04:40:02 Tower kernel: ata4.01: error: { ICRC ABRT } Sep 30 04:40:02 Tower kernel: ata4: soft resetting link Sep 30 04:40:02 Tower kernel: ata4.00: configured for UDMA/133 Sep 30 04:40:02 Tower kernel: ata4.01: configured for UDMA/33 Sep 30 04:40:02 Tower kernel: ata4: EH complete Sep 30 04:40:02 Tower kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Sep 30 04:40:02 Tower kernel: ata4.01: BMDMA stat 0x66 Sep 30 04:40:02 Tower kernel: ata4.01: failed command: WRITE DMA EXT Sep 30 04:40:02 Tower kernel: ata4.01: cmd 35/00:00:00:68:6b/00:04:00:00:00/f0 tag 0 dma 524288 out Sep 30 04:40:02 Tower kernel: res 51/84:e1:1f:68:6b/84:03:00:00:00/f0 Emask 0x30 (host bus error) Sep 30 04:40:02 Tower kernel: ata4.01: status: { DRDY ERR } Sep 30 04:40:02 Tower kernel: ata4.01: error: { ICRC ABRT } Sep 30 04:40:02 Tower kernel: ata4: soft resetting link Sep 30 04:40:02 Tower kernel: ata4.00: configured for UDMA/133 Sep 30 04:40:03 Tower kernel: ata4.01: configured for UDMA/33 Sep 30 04:40:03 Tower kernel: sd 4:0:1:0: [sde] Sep 30 04:40:03 Tower kernel: Result: hostbyte=0x00 driverbyte=0x08 Sep 30 04:40:03 Tower kernel: sd 4:0:1:0: [sde] Sep 30 04:40:03 Tower kernel: Sense Key : 0xb [current] [descriptor] Sep 30 04:40:03 Tower kernel: Descriptor sense data with sense descriptors (in hex): Sep 30 04:40:03 Tower kernel: 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00 Sep 30 04:40:03 Tower kernel: 00 6b 68 1f Sep 30 04:40:03 Tower kernel: sd 4:0:1:0: [sde] Sep 30 04:40:03 Tower kernel: ASC=0x47 ASCQ=0x0 Sep 30 04:40:03 Tower kernel: sd 4:0:1:0: [sde] CDB: Sep 30 04:40:03 Tower kernel: cdb[0]=0x8a: 8a 00 00 00 00 00 00 6b 68 00 00 00 04 00 00 00 Sep 30 04:40:03 Tower kernel: end_request: I/O error, dev sde, sector 7038976 Sep 30 04:40:03 Tower kernel: quiet_error: 374 callbacks suppressed Sep 30 04:40:03 Tower kernel: Buffer I/O error on device sde, logical block 879872 Sep 30 04:40:03 Tower kernel: lost page write due to I/O error on sde Sep 30 04:40:03 Tower kernel: Buffer I/O error on device sde, logical block 879873 Sep 30 04:40:03 Tower kernel: lost page write due to I/O error on sde Sep 30 04:40:03 Tower kernel: Buffer I/O error on device sde, logical block 879874 Sep 30 04:40:03 Tower kernel: lost page write due to I/O error on sde Sep 30 04:40:03 Tower kernel: Buffer I/O error on device sde, logical block 879875 Sep 30 04:40:03 Tower kernel: lost page write due to I/O error on sde Sep 30 04:40:03 Tower kernel: Buffer I/O error on device sde, logical block 879876 Sep 30 04:40:03 Tower kernel: lost page write due to I/O error on sde

Pretty much, In my case, I had /tmp/preclear_report_sdc. But there are a bunch of files and smart reports there that you may or may not want to keep. So you can: cd /tmp cp preclear* /boot/logs/ cp smart* /boot/logs/ I'm not sure where your /logs is but it should be something like /boot/logs/

Look in /tmp/preclear*

Pretty much what I suggested, but I don't think Unraid will even build parity(if the new parity is zero'd) or format the new[old parity] 1 TB Drive when added as data. @pengrus...good thing no one's life depends on you being 99% right. j/k. Your way also works but involves many extra steps and destroying a second copy of data that was on the old parity. I'll expand: This is actually a special degenerate case of XOR parity. When there are only 2 drives, 1 data and 1 parity, and the parity and the data drives are equal in size, the parity will be an exact bit for bit duplicate of the data drive, files/directories in all. If you XOR anything with itself, the answer is 0. So if you preclear a parity drive to all 0s and then you have 2 data drives that are exactly the same, then the parity is valid for the drives. Magic(well logic)! If you then pull the parity and add it as data, a new parity will also be all 0s since anything XOR'd with 0 is itself. Reminds me of an old computer architecture interview question I once got: If you have 2 and only 2 registers, one containing data A and another containing data B, How do you swap the contents of the registers?(remember you have no extra registers to hold a temp value)

So the verdict is....Bad backplane channel. Swapped cables and it didn't work. Swapped locations in the 5in3 and it's working. It's really odd, since in all cases the drive was identified by bios but either had failed DMA read or wasn't even detected once Unraid boot. If it was a hardware issue, I would have thought it wouldn't even have been detected by BIOS.

You don't need to do a parity swap, just put in the 2TB drive as parity, when you then change(re-assign) the 1TB parity drive as a data drive, it will contain the exact same data as the the original data drive. You could probably just add the 2TB as parity and assign the original parity as data all in one shot. But, yes preclear the new 2TB first.

I ordered a bunch of locking cables from monoprice so we'll see. It could also be the backplane(It's in an Icydock 5in3 enclosure, so if the cable swap doesn't work I'll swap locations in the cage) It's one of the 4 MB sata ports on an old Asus P5LD2-VM R2.0. It doesn't even have an AHCI setting. At least it wasn't the drive(s) I was trying to preclear. That's still going fine so far on the other port.

Could this be caused by a bad cable, or is it perhaps a bad sata channel on the MB? I tried 3 drives on that slot and all give the same failed READ DMA symptoms. When I tried to preclear a drive, it was spewing failed DMA reads into the syslog and also dropping down to UDMA/33, umda2. Moved the new drive to a different port and it's preclearing at 130MB/s to 150MB/s BIOS and unraid does detect the correct drive parameters on the bad port though, so maybe it's just spotty or a bad connection. root@Tower:/var/log# grep -i ata2.01 syslog Sep 24 21:03:08 Tower kernel: ata2.01: ATA-8: ST32000542AS, 6XW1LFNB, CC35, max UDMA/133 Sep 24 21:03:08 Tower kernel: ata2.01: 3907029168 sectors, multi 16: LBA48 NCQ (depth 0/32) Sep 24 21:03:08 Tower kernel: ata2.01: configured for UDMA/133 Sep 24 21:03:33 Tower kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Sep 24 21:03:33 Tower kernel: ata2.01: BMDMA stat 0x66 Sep 24 21:03:33 Tower kernel: ata2.01: failed command: READ DMA Sep 24 21:03:33 Tower kernel: ata2.01: cmd c8/00:20:00:00:00/00:00:00:00:00/f0 tag 0 dma 16384 in Sep 24 21:03:33 Tower kernel: ata2.01: status: { DRDY ERR } Sep 24 21:03:33 Tower kernel: ata2.01: error: { ICRC ABRT } Sep 24 21:03:33 Tower kernel: ata2.01: configured for UDMA/133 root@Tower:/var/log# grep -i ata1.01 syslog Sep 24 21:03:08 Tower kernel: ata1.01: ATA-8: ST4000DM000-1F2168, W3009RHV, CC52, max UDMA/133 Sep 24 21:03:08 Tower kernel: ata1.01: 7814037168 sectors, multi 16: LBA48 NCQ (depth 0/32) Sep 24 21:03:08 Tower kernel: ata1.01: configured for UDMA/133 root@Tower:/var/log# grep -i ata1.00 syslog Sep 24 21:03:08 Tower kernel: ata1.00: ATA-8: Hitachi HDS5C3020ALA632, ML0220F30N84ED, ML6OA580, max UDMA/133 Sep 24 21:03:08 Tower kernel: ata1.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 0/32) Sep 24 21:03:08 Tower kernel: ata1.00: configured for UDMA/133 root@Tower:/var/log# grep -i ata1.01 syslog Sep 24 21:03:08 Tower kernel: ata1.01: ATA-8: ST4000DM000-1F2168, W3009RHV, CC52, max UDMA/133 Sep 24 21:03:08 Tower kernel: ata1.01: 7814037168 sectors, multi 16: LBA48 NCQ (depth 0/32) Sep 24 21:03:08 Tower kernel: ata1.01: configured for UDMA/133 root@Tower:/var/log# tail syslog Sep 24 21:04:13 Tower ntpd[1040]: new interface(s) found: waking up resolver Sep 24 21:04:21 Tower kernel: NTFS driver 2.1.30 [Flags: R/W MODULE]. Sep 24 21:04:54 Tower in.telnetd[4775]: connect from 192.168.0.100 (192.168.0.100) Sep 24 21:04:56 Tower logger: s3_sleep: Disk activity detected. Reset all counters Sep 24 21:04:56 Tower login[4776]: ROOT LOGIN on '/dev/pts/0' from '192.168.0.100' Sep 24 21:05:56 Tower logger: s3_sleep: Disk activity detected. Reset all counters Sep 24 21:06:56 Tower logger: s3_sleep: Disk activity detected. Reset all counters Sep 24 21:07:56 Tower logger: s3_sleep: Disk activity detected. Reset all counters Sep 24 21:08:01 Tower login[4464]: ROOT LOGIN on '/dev/tty1' Sep 24 21:08:28 Tower kernel: sdc: unknown partition table

I just got a 2 port docking station but they do make 4 port docks(a little pricey vs 2 port though) http://www.startech.com/HDD/Docking/4-Bay-eSATA-USB-3-to-SATA-Hard-Drive-Docking-Station-for-25-35-HDD~SATDOCK4U3E For enclosures, there are a bunch on newegg(raid and non-raid, usb2/3 and esata, though that requires a multiplier compatible port) http://www.newegg.com/Product/Product.aspx?Item=N82E16817707274 http://www.newegg.com/Product/Product.aspx?Item=N82E16817198047 http://www.newegg.com/Product/Product.aspx?Item=N82E16817998053

Got a pair. Thanks!

That motherboard doesn't have a built in speaker, so did you hook one up to the header? That may explain the lack of beeps. I did have a bad MSI 890gxm motherboard once and it also did not have any output. I returned it and the next one worked.

With 7200 rpm drives, I've stuffed a bit of paper between the latch to lessen vibrations. It was ghetto but it helped. I'd love to hear better suggestions. I was tempted to put some sugru or silicone on the latch but never did. 5400/5900 drives haven't been as bad.

Can you explain the exact steps you took? Also what version of unraid are you running? Normally, when you upgrade a disk, you just replace it with the new one and start the array. The array does not rebuild parity since it uses parity plus the other disks to rebuild the upgraded disk. By hitting format, you may have inadvertently told unraid to format the new disk and then rebuild parity with the formatted disk thereby ruining the parity. Hopefully you kept the old disk around. While you could have used the old disk and the parity drive to rebuild md10, the parity may not be valid any longer. Double check that you didn't jostle md10's data cable or power when you swapped md6. Then retry running reiserfsck if you think it was a data/power cable issue. Other than that, hopefully others have suggestions. Also, if you don't have a UPS, invest in one ASAP.

Online or in stores. No Rebate required. http://www.frys.com/product/6554753?site=sr:SEARCH:MAIN_RSLT_PG

I don't think so. The slowest PCI was 32bits at 33MHz or 133 MB/s.

Or buy the plus now and find a buddy who also had a plus key to share the upgrade to pro later. Would that be kosher?

He means it's only $9 more than buying the pro key upfront 69+59 = 119 +9.

When you unassigned the disk, did you restore or initconfig the array? That might have been a fatal extra step since it told the array to recompute parity as if the bad disk didn't exist. Then you lost the ability to rebuild it. This is also why when you added the new disk, it just formatted it as if it were a fresh disk new to the array. I think the correct way would have been to just remove the bad disk and replace it with the new disk and start the array which would have rebuilt the contents of the old disk onto the new one. Hopefully I'm wrong and you can recover your data another way. after the original disk failed i unassigned it from the array disks then physically removed it and rma'd it out. once the replacement came in i installed it to the same physical location then ran the preclear. once that was done i added it to the devices and the unraid showed that there was a unformatted drive. i selected the format checkmark and proceeded onward. the unraid formatted the drive and proceeded to rebuild the array automatically. and that is where i am now, before the rebuild i could navigate to the disk4 and see all the data and access it normally. thanks James

FWIW, I have the same motherboard and it does the same thing. I've never seen the AHCI or native sata mode in the bios. It seems to work fine though. I think the fact that drives are recognized as /dev/sd[abc] does mean they are detected as sata. Try setting up your array/preclearing etc and see if everything seems normal.

I don't think this needs to be done on the stacker....just the 590. At least I never had to do it with mine.

I guess it's originally from Norco and does indeed seem to work with unraid. http://lime-technology.com/forum/index.php?topic=3453.30

How about this: http://www.habeyusa.com/products_show.php?id=225&menu=1 http://cgi.ebay.com/NS-520-5-bay-Network-Storage-Appliance-/120674736188 Seems like a pretty reasonable setup if it's compatible.

Hi Matt, Very helpful post. I used your instructions, but there are a few modifications/optimizations that I did:

I'm using one with mine. APCUPSD seemed to recognize it when attached via the USB cable. I posted about it a while back maybe you can find it with a search.