Re: NCQ general question

[Jeff Garzik <jeff@garzik.org>]

Steve Byan wrote:
> On Mar 1, 2006, at 8:55 AM, Jens Axboe wrote:
> The problem with TCQ is that the host can't disconnect on writes  after 
> sending the data to the drive but before receiving the status.  The host 
> can only disconnect between sending the command and moving  the data. 

That, but also:  The standard PCI IDE hardware interface prevents the 
device from selecting command $N's DMA data out of $M active write commands.

With reads, the device has more freedom to process the requests 
asynchronously.


> Consequently TCQ is useless for writes, which is where you  really need 

Agreed.


> 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?  AFAIK TCQ has -never- applied to ATAPI.


> The reason you need write queuing is for data integrity reasons, not  
> for performance. ATA disks effectively get command-queuing on writes  
> even without TCQ and NCQ - they simply park the data in a volatile  RAM 
> cache, tell the host that the data is saved on persistent  storage, and 
> then asynchronously write the queued data to the  physical media. The 
> drive reorders those writes and will gather  sequential writes.

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.


> However, note that all filesystems that make even a pretense of  trying 
> to maintain filesystem integrity after a power failure (note  that the 
> Windows NT implementation of FAT32 does not attempt to  maintain 
> filesystem integrity after a power failure) depend on  knowing when data 
> makes it to persistent storage, so they can order  their writes 

True.


> 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.

	Jeff