hey guys,

 

after weeks of reading and decisionmaking i build my first unraid server containing mostly recommended parts :

 

ASUS P5B-VM DO + 4GB Corsair 6400 RAM

2x 1,5 TB Seagate 7200.11

Lexar 4GB JD FireFly USB Stick

 

after configurin and upgradin the bios (controller SATA1 is set to AHCI)

 

i assigned the parity drive and disk1 ... right now initzialisin is started.

 

but i noticed error messages in the syslog regarding the disk detection. it looks like the controller is fallin back to 1.5Gbit .. .the disks are jumpered to 3.0Gbit Mode (all jumpers removed as stated in the manual)

 

parity is buildin up and inizialisin are running now with around 58MB/s .. after my reading here in the forum it should be okay i guess?

 

can someone shed some light?

 

here is the syslog : http://pastebin.com/m1afcaf4a

 

thanks a lot!

I'd suggest posting your entire syslog to give RobJ a chance to have a look.

 

58 MB/sec seems okay speed.  I'd expect a bit better with those drives thought.  I get that speed with a 14 drive array containing a mix of 500G, 750G and 1T drives, including WD Green drives.

 

I'd expect you to get 80+ MB/sec.

 

Post your log and we'll go from there. 

Okay got the syslog now :

 

http://pastebin.com/m1afcaf4a

 

Hope its be of help! thanks for looking at my problem

 

Edit : After finishing and formating, somewhat is definatly wrong. I just get around 5mb/s to write to the array an smartctl is showing a lot of errors

 

eth0 shows 1000MB/s FULL, and to my other linux machine i get around 40mb with samba ... so i guess the networkpart should be okay.

 

okay just to make it a little more confusing, i started a parity check and got this :

 

Total size:  1,465,138,552  KB

Current position: 15,489,920 (1.0%)

Estimated speed: 100,579 KB/sec

Estimated finish: 240.2 minutes

 

could that be? and on the smartctl output, i read that new seagate discs start of with pretty high values ... so its fine i guess.

 

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   108   099   006    Pre-fail  Always       -       19961231
  3 Spin_Up_Time            0x0003   099   099   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       8
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   100   253   030    Pre-fail  Always       -       55365
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       9
10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       7
184 Unknown_Attribute       0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   068   067   045    Old_age   Always       -       32 (Lifetime
Min/Max 23/33)
194 Temperature_Celsius     0x0022   032   040   000    Old_age   Always       -       32 (0 22 0 0)
195 Hardware_ECC_Recovered  0x001a   053   040   000    Old_age   Always       -       19961231
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       1861181128048
73
241 Unknown_Attribute       0x0000   100   253   000    Old_age   Offline      -       1214222139
242 Unknown_Attribute       0x0000   100   253   000    Old_age   Offline      -       2896715536

I just get around 5mb/s to write to the array

 

eth0 shows 1000MB/s FULL, and to my other linux machine i get around 40mb with samba

 

Somewhere there is a good guide to getting units correct, but I can't think where.  They do make a big difference.  Above, 1000MB/s should be 1000Mb/s, also can be expressed as 1000Mb/sec or 1000mbps.  Small b is used for bits and capital B is used for bytes.  So 1000Mb/s is equivalent to 125MB/s, which is the theoretical top speed of a gigabit connection, but unattainable due to latency issues.  The 40mb above should be 40MB/s, which is a very good transfer speed.  The 5mb/s above should be 5MB/s, which is a very bad transfer speed!  I suspect you may have attempted a transfer while a parity sync or parity check was in progress?  They have a huge impact on performance.

 

The syslog stops abruptly at 16:12:51, prior to formatting the drive, just after the MBR's are written to both drives.  There is only one issue in this syslog, as you mentioned, and discussed below.  Otherwise, it appears to be properly preparing 2 brand new drives.  Can you post a copy of a more current syslog?

 

Mar 7 06:53:37 Tower kernel: ata2.00: qc timeout (cmd 0x27)

Mar 7 06:53:37 Tower kernel: ata2.00: failed to read native max address (err_mask=0x4)

Mar 7 06:53:37 Tower kernel: ata2.00: HPA support seems broken, skipping HPA handling

Mar 7 06:53:37 Tower kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 7 06:53:37 Tower kernel: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x100)

Mar 7 06:53:37 Tower kernel: ata2.00: revalidation failed (errno=-5)

Mar 7 06:53:37 Tower kernel: ata2: limiting SATA link speed to 1.5 Gbps

Mar 7 06:53:37 Tower kernel: ata2.00: limiting speed to UDMA/133:PIO3

Mar 7 06:53:37 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

Mar 7 06:53:37 Tower kernel: ata2.00: configured for UDMA/133

Mar 7 06:53:37 Tower kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x1 t4

Mar 7 06:53:37 Tower kernel: ata2: irq_stat 0x0c000000, interface fatal error

Mar 7 06:53:37 Tower kernel: ata2.00: configured for UDMA/133

Mar 7 06:53:37 Tower kernel: ata2: EH complete

 

As you said, this is worrisome, not right, but it does not actually say what is wrong.  Ignore the HPA stuff (and native max address line) at the top.  They are normal for this drive model.  But "failed to IDENTIFY" and "revalidation failed" and "limiting SATA link speed" and "limiting speed to UDMA/133:PIO3" and obviously "interface fatal error" are unexpected, undesirable, and wrong.  That last one I have never seen before!  When you have a chance, I would power off and check and reseat all of the SATA connections, try a new (and better?) SATA cable, and especially, reconnect to a different SATA port.  There is not enough identifiable info above to say if it is a problem with the drive, the cable, or the controller.  Performance would have been slowed, but should not be terrible.  The PIO3 has a much bigger impact than the SATA 1.5 does.

 

Current position:    15,489,920    (1.0%)

Estimated speed:    100,579    KB/sec

 

Wow, that is fast!  But is possible with the newest drives, faster than I have seen though.  That's about 100MB/s.  One thing to remember, the numbers aren't very accurate for the first percentage points.  This was only at 1%, I'd wait for a more accurate number and time forecast at around 3% or more.

 

Your SMART report looks fine.  Don't be thrown by those large RAW_VALUE's and any of the 240's.  Drive manufacturer's seem to have a lot of leeway in determining what those numbers mean and which ones they will use and how they will use them.  You have to evaluate each SMART report in the context of who the manufacturer is, and what the drive model is.  Your drives are Seagates, so they have large RAW_VALUE's for Raw_Read_Error_Rate and Hardware_ECC_Recovered, but the important thing for those is the value in the VALUE column, and it is fine.

 

The numbers in the 240's do not as yet seem to have an official interpretation, and by their size are very alarming.  I would like to ask Brian to consider dropping them from the display of MyMain, to avoid needlessly scaring users.  For now, I would say just ignore 240, 241, and 242.

Thanks again for looking at my problem and clarifying things. I waited until parity build up completly until i transfert the first files.

 

Also i switched both drives from SATA Port 1,2 to 3,4 and used different cables. To me, it looks like the disks are now inizialized with propper SATA 3 and UDMA/133 but it still remains the same writing is about 5-6 Mb/s which is not pretty usuable What should I expect with this hardware? Around 15Mb/s ?

 

Find a more recent Syslog here : http://pastebin.com/m2d5c9453

 

And sorry, seems like i missinterpreted the parity speed

so im good on that end, actually it gets even better :

 

Total size:  1,465,138,552  KB

Current position: 78,539,900 (5.3%)

Estimated speed: 125,912 KB/sec

Estimated finish: 183.5 minutes

Sync errors: 0

You have to be happy about that parity check speed.  125 MB/sec is about the fastest I've seen!

 

I have that same motherboard, and also experience VERY slow write performance with 4.4.2.  See THIS thead.

 

If you read that thread you will see that by altering the queue_depth, I was able to get good (relatively speaking) write performance.  Can you try making that change as well and see if your write performacne gets faster?

for sure im happy with the parity speed check, but i guess its hardly the case i need to check parity, or at least let it run by a cronjob when im not home. so not such big of a difference, otherwise correct me. waiting for a file to copy is way more anoying.

 

i allready tested reverting back to 4.3.3 just to see if it makes a difference. i guess i missed to copy the superblock.dat file (i used another stick) so the parity build started after reboot... is this correct? just for my understanding, in the super.dat is the current status saved of your raid? and is it possible to go back to 4.4.2 by copying the file without a need to rebuild parity?

 

and thanks for pointing me to the NCQ i disabled it and right now i get around 15Mb/s bevor it was no big difference to 4.3.3 ... i will check out the behaviour with 4.2.2 now ....

Changing between 4.3.3 and 4.4.2 is just a matter of 2 files, bzimage and bzroot.  I have both sets on my flash disk and just rename them to select what version I want to boot.

 

You should not be switching USB sticks, as the "config" folder contains information that applies to your array no matter which version is running.

 

Did I understand you right that changing the queue_depth to "1" addressed your write performance issue?

Tom, if you are reading, is this a problem that you are tracking?

sorry for the delayed reply, i started filling up the 1,5tb on sunday and it took me two days. and thanks for clearify the update process. i changed back to 4.4.2 copied the super.dat and did a parity check... looking fine so far.

 

Then i tried disableing the NCQ on 4.4.2 and i get similar results .. write speed is going from 5Mb/s to around 9-12Mb/s not as fast as 4.3.3 but i guess ill have to live with it..

So it definatly looks that the NCQ is responsible for the speed decrease ...