>Moved to -scsi...
>
>Justin, as Mr. SCSI (can i call you that? :) ) I'd like to ask you
>something
Although my domain name may confuse people, I'm just *A* SCSI Guy,
not *the* SCSI Guy. I think "Mr." is too close to the latter.
>> > > This is worse than expected, try to use option ATA_ENABLE_WC
>> > > and see what gives, if its not back to normal we have to look elsewhere.
>> >
>> > Mr ATA, is there no ATA command to "syncronize cache" like in SCSI?
>>
>> Yes, there is, and the ATA driver even uses it, the problem is WHEN
>> to use it. I originally made it flush the cache if a write contained
>> the BIO_ORDERED bit, but that doesn't work with softupdates..
>> If somebody can come up with a way to tell me when I need to flush
> the write cache, then I'll happily add that..
>
>Justin, I've heard that SCSI knows when to send sync-cache commands
>to the disks, how does the driver know when to do this based on
>the bio request?
We don't do anything so fancy. On final close, a synchronize cache
command is issued. We don't actively enable or disable write caching,
but instead leave this up to the user to configure (via camcontrol or,
in some cases, through their controller's BIOS). SCSI also provides
"Force Unit Access" that is settable on a per-command basis, but I don't
know that the SCSI spec is clear on whether having an ordered tagged
transaction complete that has the FUA bit set guarantees that all
previous commands have actually hit the disk. Even if the spec did,
it would be dangerous to assume that all devices are compliant. I
do believe, however, that SCSI does guarantee that, even with write
caching enabled, an ordered tagged transaction will only appear on
the media after all transactions queued before it have been committed.
Again, whether a particular drive honors this is anyones guess.
As for dd, it is not a great test of the true impact of disabling
write caching. dd pays a high latency penalty because it completely
serializes transactions to the disk. When going through the filesystem,
writes are performed in batches without preventing other transactions
from occurring in the mean time. This is when tagged queuing really
pays off.
--
Justin
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message