linux-kernel - Re: SATA RAID5 speed drop of 100 MB/s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <467F0272.9070903@rtr.ca>
Date:	Sun, 24 Jun 2007 19:46:58 -0400
From:	Mark Lord <lkml@....ca>
To:	Carlo Wood <carlo@...noe.com>,
	Justin Piszcz <jpiszcz@...idpixels.com>,
	Michael Tokarev <mjt@....msk.ru>,
	"Dr. David Alan Gilbert" <linux@...blig.org>,
	Jeff Garzik <jeff@...zik.org>, Tejun Heo <htejun@...il.com>,
	Manoj Kasichainula <manoj@...com>,
	linux-kernel@...r.kernel.org,
	IDE/ATA development list <linux-ide@...r.kernel.org>
Subject: Re: SATA RAID5 speed drop of 100 MB/s

Carlo Wood wrote:
>
> The following can be observed:
> 
> 1) There is hardly any difference between the two schedulers (noop
>    is a little faster for the bonny test).
> 2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s),
>    the NCQ depth of 2 is by far the slowest for the RAID5 (bonnie;
>    around 40 MB/s). NCQ depths of 3 and higher show no difference,
>    but are also slow (bonnie; around 75 MB/s).
> 3) There is no significant influence of the NCQ depth for non-RAID,
>    either the /dev/sda (hdparm -t) or /dev/sdd disk (hdparm -t and
>    bonnie).
> 4) With a NCQ depth > 1, the hdparm -t measurement of /dev/md7 is
>    VERY unstable. Sometimes it gives the maximum (around 150 MB/s),
>    and sometimes as low as 30 MB/s, seemingly independent of the
>    NCQ depth. Note that those measurement were done on an otherwise
>    unloaded machine in single user mode; and the measurements were
>    all done one after an other. The strong fluctuation of the hdparm
>    results for the RAID device (while the underlaying devices do not
>    show this behaviour) are unexplainable.
> 
>>>From the above I conclude that something must be wrong with the
> software RAID implementation - and not just with the harddisks, imho.
> At least, that's what it looks like to me. I am not an expert though ;)

I'm late tuning in here, but:

(1) hdparm issues only a single read at a time, so NCQ won't help it.

(2) WD Raptor drives automatically turn off "read-ahead" when using NCQ,
which totally kills any throughput measurements.  They do this to speed
up random access seeks; dunno if it pays off or not.  Under Windows,
the disk drivers don't use NCQ when performing large I/O operations,
which avoids the performance loss.

(3) Other drives from other brands may have similar issues,
but I have not run into it on them yet.

Cheers

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/