From: Greg Stark <gsstark@mit.edu>
To: "Eric D. Mudama" <edmudama@gmail.com>
Cc: Greg Stark <gsstark@mit.edu>, Jens Axboe <axboe@suse.de>,
Matthias Andree <matthias.andree@gmx.de>,
linux-kernel@vger.kernel.org, jgarzik@pobox.com
Subject: Re: [PATCH] SATA NCQ support
Date: 30 May 2005 02:21:56 -0400 [thread overview]
Message-ID: <87d5r9xmgr.fsf@stark.xeocode.com> (raw)
In-Reply-To: <311601c905052921046692cd3e@mail.gmail.com>
"Eric D. Mudama" <edmudama@gmail.com> writes:
> If used properly, I don't feel write cache "destroys" data integrity,
> you just need to get your power failure tolerance elsewhere.
That doesn't help if your power failure is caused by a failed UPS or a power
supply or other circuit after said "elsewhere" ... People do expect not to
have a simple power event mean having to do a complete restore of their
database from backups.
> ATA has a limitation of 32 tags, so queued write cache off won't beat
> unqueued write cache on in any modern drive.
People earlier were quoting 30-40% gains with NCQ enabled. I assumed those
were with the same drive in otherwise the same configuration, presumably with
write-caching enabled.
Without any form of command queueing write-caching imposes a severe
performance loss, the question is how much of that loss is erased when NCQ is
present.
> The real reason most SCSI drives do so well uncached is they use huge
> magnets with short, stiff actuators, smaller platters, and they spin
> significantly faster. NCQ certainly helps, but spending more money on
> mechanics makes a significant difference. Pick up a SCSI drive and an
> ATA drive, you'll feel the SCSI weighs seemingly twice as much.
People do take average seek latency and rotational latency into account when
they post numbers. There's no question faster drives are, well, faster.
People actually tend to report that IDE drives are *faster*. Until they're
told they have to disable write-caching on their IDE drives to get a fair
comparison, then the performance is absolutely abysmal. The interesting thing
is that SCSI drives don't seem to take much of a performance hit from having
write-caching disabled while IDE drives do.
--
greg
next prev parent reply other threads:[~2005-05-30 6:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-27 7:03 [PATCH] SATA NCQ support Jens Axboe
2005-05-27 7:22 ` Jeff Garzik
2005-05-27 7:30 ` Jens Axboe
2005-05-27 7:37 ` Jeff Garzik
2005-05-27 7:47 ` Jens Axboe
2005-05-27 7:56 ` Jens Axboe
2005-05-27 8:24 ` Jeff Garzik
2005-05-27 8:27 ` Jeff Garzik
2005-05-27 8:28 ` Jeff Garzik
2005-05-27 8:35 ` Jens Axboe
2005-05-27 8:38 ` Jeff Garzik
2005-05-27 8:42 ` Jens Axboe
2005-05-27 23:47 ` Jeff Garzik
2005-05-27 13:18 ` Matthias Andree
2005-05-27 13:53 ` Jens Axboe
2005-05-27 14:46 ` Matthias Andree
2005-05-27 14:58 ` Jens Axboe
2005-05-29 13:16 ` Matthias Andree
2005-05-29 16:36 ` Jeff Garzik
2005-05-30 2:35 ` Eric D. Mudama
2005-05-30 3:41 ` Greg Stark
2005-05-30 4:04 ` Eric D. Mudama
2005-05-30 6:21 ` Greg Stark [this message]
2005-05-30 6:33 ` Jens Axboe
2005-05-30 12:16 ` Jens Axboe
2005-05-30 12:37 ` Jens Axboe
2005-05-30 14:51 ` Jens Axboe
2005-05-27 16:00 ` Jeff Garzik
[not found] <48Hix-88s-7@gated-at.bofh.it>
[not found] ` <48N4N-4B5-25@gated-at.bofh.it>
[not found] ` <48Pzt-6Kb-5@gated-at.bofh.it>
2005-05-31 0:00 ` Robert Hancock
2005-05-31 1:21 ` Jeff Garzik
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=87d5r9xmgr.fsf@stark.xeocode.com \
--to=gsstark@mit.edu \
--cc=axboe@suse.de \
--cc=edmudama@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthias.andree@gmx.de \
/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