From: Mark Rustad <mrustad@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-kernel@vger.kernel.org,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: Why is NCQ enabled by default by libata? (2.6.20)
Date: Tue, 27 Mar 2007 17:12:00 -0500 [thread overview]
Message-ID: <711F1620-F483-4CC2-83D6-F2DD577AB5BB@gmail.com> (raw)
In-Reply-To: <460964BA.8090101@garzik.org>
On Mar 27, 2007, at 1:38 PM, Jeff Garzik wrote:
> Mark Rustad wrote:
>> reorder any queued operations. Of course if you really care about
>> your data, you don't really want to turn write cache on.
>
> That's a gross exaggeration. FLUSH CACHE and FUA both ensure data
> integrity as well.
>
> Turning write cache off has always been a performance-killing
> action on ATA.
Perhaps. Folks I work with would disagree with that, but I am not
enough of a storage expert to judge. My statement mirrors the
judgement of folks I work with that know more than I do.
>> Also the controller used can have unfortunate interactions. For
>> example the Adaptec SAS controller firmware will never issue more
>> than two queued commands to a SATA drive (even though the firmware
>> will happily accept more from the driver), so even if an attached
>> drive is capable of reordering queued commands, its performance is
>> seriously crippled by not getting more commands queued up. In
>> addition, some drive firmware seems to try to bunch up queued
>> command completions which interacts very badly with a controller
>> that queues up so few commands. In this case turning NCQ off
>> performs better because the drive knows it can't hold off
>> completions to reduce interrupt load on the host – a good idea
>> gone totally wrong when used with the Adaptec controller.
>
> All of that can be fixed with an Adaptec firmware upgrade, so not
> our problem here, and not a reason to disable NCQ in libata core.
It theoretically could be, but we are using the latest Adaptec
firmware. Until there exists firmware that fixes it, it remains an
issue. We worked with Adaptec to isolate this issue, but no
resolution has been forthcoming from them. I agree that this does not
mean that NCQ should be disabled in libata core, but some combination
of controller/drive/firmware blacklist may need to be managed, as
distasteful as that is.
>> Today SATA NCQ seems to be an area where few combinations work
>> well. It seems so bad to me that a whitelist might be better than
>> a blacklist. That is probably overstating it, but NCQ performance
>> is certainly a big problem.
>
> Real world testing disagrees with you. NCQ has been enabled for a
> while now. We would have screaming hordes of users if the majority
> of configurations were problematic.
I didn't say that it is a majority or that it doesn't work, it just
often doesn't perform. If it didn't work there would be lots of
howling for sure. I'm also not saying that it is a libata problem. It
seems mostly to be controller and drive firmware issues - and the odd
fan issue (if you saw the thread: [BUG 2.6.21-rc3-git9] SATA NCQ
failure with Samsum HD401LJ).
I guess I am mainly lamenting the current state of SATA/NCQ devices
and sharing what little I have picked up about it - which is that I
want SAS disks in my next system!
--
Mark Rustad, MRustad@gmail.com
next prev parent reply other threads:[~2007-03-27 22:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-24 16:38 Justin Piszcz
2007-03-24 18:43 ` Alan Cox
2007-03-27 9:55 ` Justin Piszcz
2007-03-27 10:10 ` Tejun Heo
2007-03-27 10:30 ` Justin Piszcz
2007-03-27 5:59 ` Jeff Garzik
2007-03-27 14:26 ` Mark Lord
2007-03-27 18:18 ` Mark Rustad
2007-03-27 18:38 ` Jeff Garzik
2007-03-27 22:12 ` Mark Rustad [this message]
2007-03-31 12:55 ` Ric Wheeler
[not found] <fa.MhN9pBMjZID4rnTNn+fU01uZiss@ifi.uio.no>
2007-03-24 22:11 ` Robert Hancock
2007-03-27 16:16 linux
2007-03-27 16:25 ` Justin Piszcz
2007-03-27 16:41 ` linux
2007-03-27 16:44 ` Justin Piszcz
2007-03-27 16:58 ` linux
2007-03-27 17:03 ` Justin Piszcz
2007-03-28 14:42 ` Phillip Susi
2007-03-28 14:48 ` Jeff Garzik
2007-03-29 17:28 ` Phillip Susi
2007-03-29 18:40 ` linux
2007-03-29 18:51 ` Jeff Garzik
2007-03-29 21:35 ` Alan Cox
2007-03-29 21:47 ` David Schwartz
2007-03-30 16:33 ` Lennart Sorensen
[not found] <fa.NmF2xJwO4BeVbJrFRkf7oV9EYmQ@ifi.uio.no>
[not found] ` <fa.39luedDWsoqip+QMNtfAv8jvyNg@ifi.uio.no>
[not found] ` <fa.b1cZfpMNhZ0teK/UauKLDWw60Jc@ifi.uio.no>
[not found] ` <fa.xWaBy6HZTRTgI+PxinV8ajuOlJI@ifi.uio.no>
[not found] ` <fa.BiSx71HKysC9QIpS8DLip5BmfxI@ifi.uio.no>
2007-04-01 17:28 ` Robert Hancock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=711F1620-F483-4CC2-83D6-F2DD577AB5BB@gmail.com \
--to=mrustad@gmail.com \
--cc=jeff@garzik.org \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®