Date: Mon, 12 Mar 2001 15:10:24 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: "Justin T. Gibbs" <gibbs@scsiguy.com> 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: <20010312151024.E18351@fw.wintelcom.net> In-Reply-To: <200103122223.f2CMNMs39959@aslan.scsiguy.com>; from gibbs@scsiguy.com on Mon, Mar 12, 2001 at 03:23:22PM -0700 References: <20010312132922.Y18351@fw.wintelcom.net> <200103122223.f2CMNMs39959@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Justin T. Gibbs <gibbs@scsiguy.com> [010312 14:23] wrote: > >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. Ah, take it like a man. :) > >> > > 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. TMI dude. :) All i need to know is if there's a way to look at a particular struct bio/buf and determine if there's a need to write the data sync. Soren claims that B_ORDERED is not the magic bit that's needed, is there one? Or are we SOL on the kernel communicating the need for a block to be written "right now" and not complete until sync'd to the backing storage's non-volatile media? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ 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?20010312151024.E18351>