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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .