All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Steve Byan <smb@egenera.com>
Cc: Jens Axboe <axboe@suse.de>, Mark Lord <liml@rtr.ca>,
	Gentoopower <gentoopower@yahoo.de>,
	"Raz Ben-Jehuda(caro)" <raziebe@gmail.com>,
	Linux RAID Mailing List <linux-raid@vger.kernel.org>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: NCQ general question
Date: Sat, 04 Mar 2006 14:10:27 -0500	[thread overview]
Message-ID: <4409E623.5070707@garzik.org> (raw)
In-Reply-To: <98B59AFC-2781-4A8A-82E4-C923B4A48F9E@egenera.com>

Steve Byan wrote:
> 
> On Mar 3, 2006, at 5:19 PM, Jeff Garzik wrote:
> 
>> Steve Byan wrote:
>>
>>> it. It works OK for reads. TCQ was really invented as a  way to  
>>> allow CD-ROM drives to play nice on the same ATA bus as disks.
>>
>>
>> Disagree, you are probably thinking about bus disconnect associated  
>> with the overlapped command set?
> 
> 
> Yep, I had the two concepts confused. Thanks for the clarification.  
> Isn't the same bus disconnect used for TCQ, though?

Yes.  TCQ still has nothing to do with ATAPI though, which was the main 
point of disagreement :)  Much to my chagrin, too, since ATAPI could use 
some queueing...


>> Data integrity -and- performance.  Performance increases for all  the 
>> standard reasons that an asynchronous pipeline increases  performance 
>> over a synchronous one.
>>
>> The write cache means that requests on the device can be processed  
>> asynchronously, but without NCQ there is still a synchronous  
>> bottleneck:  the device<->controller pipe.
> 
> 
> True, but I think that is fairly small compared to no-write-cache-and- 
> no-queuing case. Write-caching is the major win; optimizing the data  
> transfer is only a second-order effect.

Measurements on NCQ in the field show a distinct performance 
improvement...  30% has been measured on Linux.  Nothing to sneeze at.


>>> correctly. ATA disk write caching breaks this guarantee.  To  restore 
>>> filesystem integrity on a careful-write filesystem like   most unix 
>>> filesystems, you have to disable write-caching in the   drive. This
>>
>>
>> False, as Linux has proven:  barriers can be implemented with flush- 
>> cache commands.
>>
>> Disabling write cache is not your only choice, and using flush- cache 
>> gives you better performance than flat-out disabling the  write cache.
> 
> 
> Yes, you're correct; I neglected to include that option. It's not as  
> good as real FUA because it flushes the entire cache, not just the  
> metadata which needs to be written through to the media.

Agreed.

	Jeff



  reply	other threads:[~2006-03-04 19:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-01  7:04 NCQ general question Raz Ben-Jehuda(caro)
2006-03-01  8:56 ` Gentoopower
2006-03-01 13:49   ` Mark Lord
2006-03-01 13:55     ` Jens Axboe
2006-03-03 21:55       ` Steve Byan
2006-03-03 22:19         ` Jeff Garzik
2006-03-04 18:56           ` Steve Byan
2006-03-04 19:10             ` Jeff Garzik [this message]
2006-03-04 20:23               ` Steve Byan
2006-03-04 23:56                 ` Eric D. Mudama
2006-03-05  7:19                   ` Raz Ben-Jehuda(caro)
2006-03-05  7:29                     ` Jeff Garzik
2006-03-08 16:51                       ` Louis-David Mitterrand
2006-03-08 17:17                         ` Jeff Garzik
2006-03-14 17:17                           ` Louis-David Mitterrand
2006-03-01 15:56     ` Gentoopower
2006-03-01 16:05       ` Jens Axboe
2006-03-01 16:20         ` Jeff Garzik
2006-03-01 18:53           ` Jens Axboe
2006-03-02  8:14             ` Raz Ben-Jehuda(caro)
2006-03-02  8:18               ` Jens Axboe
2006-03-02 11:20                 ` Jeff Garzik
2006-03-02 13:34                   ` Raz Ben-Jehuda(caro)
2006-03-02 13:37                     ` Jeff Garzik
2006-03-02  8:18           ` Rafal Krzewski
2006-03-02 11:35             ` Jeff Garzik
2006-03-02 14:29               ` Rafal Krzewski
2006-03-01 16:48         ` Gentoopower
2006-03-01 18:34           ` Mark Lord

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=4409E623.5070707@garzik.org \
    --to=jeff@garzik.org \
    --cc=axboe@suse.de \
    --cc=gentoopower@yahoo.de \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=raziebe@gmail.com \
    --cc=smb@egenera.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.