Date: Mon, 12 Mar 2001 15:23:22 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Soren Schmidt <sos@freebsd.dk>, Kevin Oberman <oberman@es.net>, scsi@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA Message-ID: <200103122223.f2CMNMs39959@aslan.scsiguy.com> In-Reply-To: Your message of "Mon, 12 Mar 2001 13:29:22 PST." <20010312132922.Y18351@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103122223.f2CMNMs39959>