4

I have four disks, of which two are WD15EARS, in a server and I'm trying to put the two WD15EARS's in Linux mdadm RAID, but for some reason, the array's performance is very slow (it syncs at about 15 MB/s). At first I thought it was an alignment issue, since they're Advanced Format drives, but I don't think so. This is how I aligned them. I also have two of these drives in my desktop PC, aligned painstakingly with LVM and RAID, and they're running fine.

I did some speed tests on the individual drives (sdb and sdd). Hdparm -t shows 80 MB/s for sdb and only 30 MB/s for sdd (and the two other drives, two Samsung ones, measure at about 100 MB/s). These results are repeatable. It also shows that it's not an alignment thing, because then hdparm -t would be slow on both drives.

I have been unable to discern any differences that might explain why one of these drives is slower, except that SMART reports the following on the good drive:

Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.

And it reports this on the bad drive:

Offline data collection status:  (0x85) Offline data collection activity
                                    was aborted by an interrupting command from host.
                                    Auto Offline Data Collection: Enabled.

The auto offline data collection should run every four hours, but the status message on the bad drive never changes.

I hypothesized that it's this offline collection that causes slowdown, but I am unable to abort it. Smartctl -X doesn't do anything, which makes sense, because the drives do not have the "Abort Offline collection upon new command" capability, according to smartctl -c.

I'm currently running a long self test which hopefully yields something, but in the meantime, I was hoping if anybody knows what might be going on.

Edit: the self test finished, it says it's OK. Turning off automatic offline data collection also didn't help.

And, I just did DD write tests. dd if=/dev/zero of=/dev/sdX bs=10M yieled 65 MB/s on the good disk and about 15 MB/s on the bad one. There's definitely something wrong.

Edit2: I picked up the drives from the datacenter and connected it to my PC with a USB to SATA converter. Now it works fine...

Improve this question
2
  • Have you tried using the Western Digital's diagnostic tools? support.wdc.com/product/…
    – 3dinfluence
    Mar 11, 2012 at 1:47
  • The server is located in the datacenter and it needs to be taken offline to do that, so that's going to be hard. But the SMART test didn't yield errors...
    – Halfgaar
    Mar 11, 2012 at 10:29

3 Answers 3

Reset to default
4

Possibly the cause for significantly decreased performance would be the Automatic Acoustic Management (AAM) - check its status on both drives using hdparm -M and disable it entirely by setting the value to 254.

Also, enabling the write cache on the drives using hdparm -W should be worth trying.

Since you are using Caviar Green drives (which you should not be doing for a Linux RAID setup, honestly) and already are at it, make sure to disable the power saving features, especially the IntelliPark feature.

If nothing helps, it might be a hardware problem indeed - open up an RMA and return the drive to WD.

Improve this answer
2
  • 1
    I second this. Please be adviced that Smart-status on these EARS drives is not always to be trusted. I personally know of 3 cases (1 15EARS, 2x 20EARS drive), out of a 240 drive sample-size (a full desktop rollout for a customer), where Smart reported OK, but the drives had flaky sectors causing excessive retries/aborts. Data Lifeguard reported the drives OK on Smart-status but crashed during verification. WD replaced them with EARX models. They appear to have terminated their EARS line completely. I wonder why....
    – Tonny
    Mar 11, 2012 at 11:29
  • I had already disabled the intellipark feature. Load cycle count is 281. Interesting to know about the termination of the EAR line, BTW. Anyway, I retrieved the drive from the datacenter and tested it with a USB-SATA converter. It works fine here... Oh, and I can't check the AM setting; it doesn't work over USB. My desktop WD15EARS drives both have 254 (fastest), so I guess that's the default.
    – Halfgaar
    Mar 11, 2012 at 13:40
1

I solved it. It turned out native SATA (AHCI) was not enabled. It works now (Array is synching with 70 MB/s) and read speads are 120 MB/s. Still, that slowness shouldn't happen in legacy mode, but at least it's gone.

I now also have proper NCQ. I used to have non-functional NCQ (dmesg|grep -i ncq: queue 0/32; the zero means the disk supports it, but controller doesn't).

Improve this answer
2
  • Goed gedaan jochie :-) That's the last thing that comes to mind in a situation a like this.
    – Tonny
    Mar 11, 2012 at 16:44
  • Later the disk died anyway, so it was probably broken...
    – Halfgaar
    Mar 28, 2012 at 7:21
-2

Check the partition alignment on 4k sectors.

http://lwn.net/Articles/322777/

Improve this answer
1
  • I know all about 4k alignment. My post reflects in detail (by means of a link to another post) how I aligned it.
    – Halfgaar
    Mar 10, 2012 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.