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?
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.
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.
Regards,
-Steve
--
Steve Byan <smb@xxxxxxxxxxx>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125
-
: 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
