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
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
