February 7, 201016 yr OK I figured out how to flash the sata board bios and it is now running a non-raid bios which is what RobJ did. Now I want to re-assign the disks to the array. I have done this but now it says 2 new disks found. I assume I need to do a restore. Please verify. Thx Yes, you need to do a "restore" to set a new disk configuration, invalidate the current parity, and start a new initial parity calc.
February 8, 201016 yr Author Parity has been built with no errors. I will be running a parity check shortly.
February 8, 201016 yr Author Well I started to get sync errors as soon as I started the parity check. I have unassigned the 2 drives again and am rebuilding parity. I am definitely thinking it is the sata board or the PCI-E slot on the motherboard. I only have one of the small PCI-E slots so I cannot move it to another one to try. Can someone please tell me what a good PCI SATA board would be for unraid? It has to be PCI because that is all I have left on the motherboard. Thx
February 8, 201016 yr Author I am thinking of getting this SATA board http://www.directcanada.com/products/?sku=15850BD4273&vpn=SD-SATA-4P&manufacture=Syba Is anyone using one of these with Unraid. Please let me know if you are and how it works. I will be using the board with the WD15EADS drives. Thx
February 8, 201016 yr I am thinking of getting this SATA board http://www.directcanada.com/products/?sku=15850BD4273&vpn=SD-SATA-4P&manufacture=Syba Is anyone using one of these with Unraid. Please let me know if you are and how it works. I will be using the board with the WD15EADS drives. Thx Not a bad price for a 4 port board. Probably as good as any.
February 8, 201016 yr Author Well I ordered one to see. I will let you know once I find out if it was the Sata board
February 8, 201016 yr Would the SATA150 PCI cause any slowdowns since it is not SATA300? Probably not, since it is a PCI card and the PCI bus limits you to 133Mb/s anyway. Joe L.
February 8, 201016 yr What hardware are you running? If you posted it I've missed it. I had trouble with a SiL3112 based card. I think it was a Syba but not sure. It looked like this one but I'm sure it wasn't Masscool. http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=3825444&CatId=1455 I tried 2 of them and they would not work. They were not upgradable to a different BIOS either. I have a ECS 740G based board. I'm believing it's a motherboard issue because I tried the board in my HTPC and it worked OK there. I'd like to try a different card one day and see what happens. FYI, you should be able to install that card into the large PCIe x16 slot just fine. Peter
February 8, 201016 yr Author Yeah I posted all of my hardware in this thread on one of the pages. I should get the card by Wednesday so I hope it works This is the one I ordered: http://www.directcanada.com/products/?sku=15850BD4273&vpn=SD-SATA-4P&manufacture=SYBA I believe it is 3114 based
February 9, 201016 yr Odd, you're using a 740g chipset based board too and you're having the exact same problems I had. Looks like there might be some kind of compatability problem here... That PCI card should be fine. Peter
February 9, 201016 yr Author Yea it must be the card because I did rebuilt parity and did a check with 0 sync errors with that board removed. Looking at the tracking of my new board it should be here today. I cannot wait to get this resolved. I will post my results.
February 9, 201016 yr Yea it must be the card because I did rebuilt parity and did a check with 0 sync errors with that board removed. Looking at the tracking of my new board it should be here today. I cannot wait to get this resolved. I will post my results. At one point you tried mounting the drives on that card outside of the array and did an md5sum on two large files. You said the checksums came out OK. This seems to prove the card can access ONE drive at a time with the block sizes used in file-access. It may be why the card is usable in most situations. When checking parity the type of access is very different. It is my understanding a "stripe" at a time is read, a stripe being several meg in size. Also, parallel access of the disks occurs. It might be that the read corruptions occur when simultaneous access occurs. If you have time, and the inclination, you might try assigning just parity and one of the two drives on the suspected board, un-assigning the others, pressing restore, and performing the parity calc/check on only one the two drives.. (It should go pretty quick) If it fails with one drive, then we'll know for sure that is the issue. If it passes, try with just the other single data drive in combination with parity. If that passes, try with the only the two drives on that board assigned in combination with parity. (leave all the other data drives un-assigned) By then, the replacement board will be at your doorstep, and you'll want to install it. I suspect your parity calc issue will be resolved... and you can stop pulling out your hair. Your experience firmly supports doing a full parity check in addition to an initial parity calc when adding drives. Joe L.
February 9, 201016 yr Author The new board is installed and all drives have been assigned. Parity is now building. Once it is done I will run a parity check and see what happens. I will post results when done. Thx
February 9, 201016 yr Joe; I did a bunch of testing on the card I had. I put the card into my HTPC with an extra 500 gig drive connected. I formatted it NTFS and could write and then read files from it just fine with MD5 checksums matching the origional on the HTPC operating system drive. I tried a number of different sized video files. I then installed the card and drive into the unRAID box and mounted the drive, repeating the connections I had before. When i read the files from the server over the network, the MD5 checksums no longer matched the origional files on the HTPC. Also, each time I repeated the checksum calculation, the checksum was a different number. So, I figure it's likely a motherboard incompatibility or the OS drivers. But then, it could have been something else like say the power supply somehow not powering the card correctly. I never went as far as doing a parity check while the card and drive were installed, mounted and being read to see if the other drives began to act up at the same time which would point to there being a bigger issue. Other than this card, the system has been flawless. I just rebooted it a few days ago and it had been up since Oct. 26 before that. Peter
February 10, 201016 yr Author Well... parity was built 100% and a parity check reported 0 errors :) Finally I can put this one to rest. I appreciate all your help Joe Thx
March 4, 201016 yr I'm running 4.4.2 and, unfortunately, it appears that I've got HPA on some of my drives. I'd like to get it fixed so I can move up to 4.5.3 (and get some peace of mind). I'll be trying the steps/suggestions listed in this thread...but did you end up having to keep the "libata.ignore_hpa=1" option? Or were you able to remove that as well?
March 7, 201016 yr Trying to bring this thread back from the dead instead of starting a new one... I'm going to give 4.5.3 a try today to make sure there is, in fact, a problem...but I've attached my syslog which talks about 'HPA detected' anyway. The syslog was too big, so I had to cut it, but hopefully the relevant parts are in there...let me know if I need to chop the file up and post the rest. syslog-HPA.txt
March 8, 201016 yr Well, 4.5.3 booted up without any major complains, but I do still see mentions of HPA being detected in the logs: Mar 7 12:53:21 Tower kernel: ata5.00: HPA detected: current 3907027055, native 3907029168 Mar 7 12:53:21 Tower kernel: ata5.00: ATA-8: ST32000542AS, CC34, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata5.00: 3907027055 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata6.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata6.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata5.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: ata6.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 7 12:53:21 Tower kernel: ata3.01: SATA link down (SStatus 4 SControl 300) Mar 7 12:53:21 Tower kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 7 12:53:21 Tower kernel: ata4.01: SATA link down (SStatus 4 SControl 300) Mar 7 12:53:21 Tower kernel: ata4.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata4.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata3.00: HPA detected: current 2930275055, native 2930277168 Mar 7 12:53:21 Tower kernel: ata3.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata3.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata4.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: ata3.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: scsi 3:0:0:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Mar 7 12:53:21 Tower kernel: scsi 4:0:0:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Should I give the hdparm commands a go? (Referring to this command: hdparm -N p1953525168 /dev/sdh). Unfortunately, I'm not sure which devices these messages are referring to, is there a way I can tell?
March 8, 201016 yr Well, 4.5.3 booted up without any major complains, but I do still see mentions of HPA being detected in the logs: Mar 7 12:53:21 Tower kernel: ata5.00: HPA detected: current 3907027055, native 3907029168 Mar 7 12:53:21 Tower kernel: ata5.00: ATA-8: ST32000542AS, CC34, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata5.00: 3907027055 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata6.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata6.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata5.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: ata6.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 7 12:53:21 Tower kernel: ata3.01: SATA link down (SStatus 4 SControl 300) Mar 7 12:53:21 Tower kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 7 12:53:21 Tower kernel: ata4.01: SATA link down (SStatus 4 SControl 300) Mar 7 12:53:21 Tower kernel: ata4.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata4.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata3.00: HPA detected: current 2930275055, native 2930277168 Mar 7 12:53:21 Tower kernel: ata3.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Mar 7 12:53:21 Tower kernel: ata3.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 7 12:53:21 Tower kernel: ata4.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: ata3.00: configured for UDMA/133 Mar 7 12:53:21 Tower kernel: scsi 3:0:0:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Mar 7 12:53:21 Tower kernel: scsi 4:0:0:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Should I give the hdparm commands a go? (Referring to this command: hdparm -N p1953525168 /dev/sdh). Unfortunately, I'm not sure which devices these messages are referring to, is there a way I can tell? Do NOT set the HPA on the wrong disk. In the same way, do NOT set it to the wrong value for YOUR disk. For each of your drives, type: hdparm -N /dev/sd? You will find the ones that show a different "current" HPA than native. Then, set the HPA to the native value for that disk. For the example drive you posted, the native size would require a you to type hdparm -N p3907029168 /dev/sdX (for the drive on ata5) and hdparm -N p2930277168/dev/sdX (for the drive on ata3) where sdX is the appropriate drive. You can look backwards in the syslog for lines with "ata5" and "ata3" to see the affiliated disk ID. zip up and attach the current syslog to your next post, now that you are on 4.5.3.
March 8, 201016 yr Thanks for the reply, Joe. I did search around for other ata5/ata3 lines, but didn't find anything that looked like it would give me the device associated with it...must've missed something! I'll upload the log once I'm home later tonight.
March 9, 201016 yr Thanks for the reply, Joe. I did search around for other ata5/ata3 lines, but didn't find anything that looked like it would give me the device associated with it...must've missed something! I'll upload the log once I'm home later tonight. It is not always really obvious: Mar 9 09:11:00 Tower kernel: ata5: SATA max UDMA/133 cmd 0xd800 ctl 0xdc00 bmdma 0xe800 irq 19 Mar 9 09:11:00 Tower kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 9 09:11:00 Tower kernel: ata5.00: HPA detected: current 3907027055, native 3907029168 Mar 9 09:11:00 Tower kernel: ata5.00: ATA-8: ST32000542AS, CC34, max UDMA/133 Mar 9 09:11:00 Tower kernel: ata5.00: 3907027055 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 9 09:11:00 Tower kernel: ata5.00: configured for UDMA/133 ata5.00 = scsi 5:0:0:0 Mar 9 09:11:00 Tower kernel: scsi 5:0:0:0: Direct-Access ATA ST32000542AS CC34 PQ: 0 ANSI: 5 Mar 9 09:11:00 Tower kernel: sd 5:0:0:0: [sde] 3907027055 512-byte logical blocks: (2.00 TB/1.81 TiB) Mar 9 09:11:00 Tower kernel: sd 5:0:0:0: [sde] Write Protect is off Mar 9 09:11:00 Tower kernel: sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00 Mar 9 09:11:00 Tower kernel: sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA and Mar 9 09:11:00 Tower kernel: ata3.00: HPA detected: current 2930275055, native 2930277168 Mar 9 09:11:00 Tower kernel: ata3.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Mar 9 09:11:00 Tower kernel: ata3.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Mar 9 09:11:00 Tower kernel: ata3.00: configured for UDMA/133 ata3.00 = scsi 3:0:0:0 Mar 9 09:11:00 Tower kernel: scsi 3:0:0:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Mar 9 09:11:00 Tower kernel: sd 3:0:0:0: [sdc] 2930275055 512-byte logical blocks: (1.50 TB/1.36 TiB) Mar 9 09:11:00 Tower kernel: sd 3:0:0:0: [sdc] Write Protect is off Mar 9 09:11:00 Tower kernel: sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 Mar 9 09:11:00 Tower kernel: sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Your two disks with an HPA are /dev/sde and /dev/sdc
March 9, 201016 yr Wow, thanks for the quick response! And thanks for pointing that out, as well...I wouldn't have realized that connection. So I'm looking at running the following two commands, yes? hdparm -N p3907029168 /dev/sde and hdparm -N p2930277168/dev/sdc Just want to double check...
Archived
This topic is now archived and is closed to further replies.