[kwlug-disc] MDADM and RAID

[Chris Irwin]

On Wed, Mar 3, 2010 at 16:22, John Van Ostrand <john at netdirect.ca> wrote:
>
> ----- "Chris Irwin" <chris at chrisirwin.ca> wrote:
>> Each sync takes about 1.5 hours, so I won't be posting my results
>> until later.
>
> The raid10 I created was finished in seconds. I chose not to zero out the device.

Well crap. My Raid0 array I decided to try didn't try to zero out and
was done immediately. The RAID1, 10, and 5 arrays did a sync by
default. I didn't override them.

> Drive cache memory. The SAS drives I'm using are 10K rpm scsi-class sata disks which are faster than typical consumer sata disks. This may allow the disk to queue more data for writing so it can efficiently write more data at once making it more efficient.

I believe all four disks have 32MB cache. Other than that they are
standard consumer 7200-rpm 500GB drives.

> Command Queuing. Depending on the SATA chipset and driver used it may not support command queuing meaning the disk may be writing the blocks as they come in rather than returning control. With Sata this is called NCQ (native command queuing) here is a doc that describes it a little more: http://forums.serverbeach.com/showthread.php?t=7333 . My CentOS 5.4 box has a queue depth of 32, my Fedora 11 box has a queue depth of 1.

Looks good on that end, though I'm not sure why it set the queue depth
to 31 instead of 32... The dd test is sequential writes, and in theory
so is an LV migration, so would NCQ have an effect here?

$ dmesg | grep NCQ
[    1.450844] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[    1.450875] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[    1.451515] ata2.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[    1.451553] ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
$ cat /sys/block/sda/device/queue_depth
31

-- 
Chris Irwin
<chris at chrisirwin.ca>