Date: Sun, 13 Jul 1997 20:34:18 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com Subject: Re: problems with reboot Message-ID: <XFMail.970714195439.Shimon@i-Connect.Net> In-Reply-To: <199707140037.SAA02750@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Justin T. Gibbs; On 14-Jul-97 you wrote: > > The shutdown code waits for all buffers to be flushed, but the code > has no > >way of knowing if the controller actually committed the data to disk. If > a > >disk controller indicates I/O completion/success before the data is > actually > >written to disk, then it seems to me that forcing the cache flush would > be > a controller specific operation. Yes? > > In this case, the DPT emulates "a giant disk" and responds to the same > commands that disks do. Lots of disks return successful completion > status on I/O that is still in there cache. So, even if there wasn't > a controller cache to worry about, you'd still want to ensure that the > cache on the disks is flushed before turning off the system. That's > why the SCSI spec gives you the synchronize cache command. We should > be issueing this on final close to all disks (the new CAM code does) > which will handle normal disks as well as RAID controllers like the DPT > that emulate disks. So, no controller specific operation is needed. Most disks we are dealing with have one megabyte of memory on the drive. I would classify DPT's response to (and the existance of) ``...MEDIA REMOVAL..' to luck more than anything else. To comply with MEDIA REMOVAL command, a device must flush his caches. But justin's choice is the correct one. > It turns out that the DPT also flushes it's cache on the "allow > media removal command" which the current code does on final close, > but I don't think that we should assume that this works in all > cases. Using that command on a device that doesn't report itself > as removable is also a little bogus. It is a questionable practie to use MEDIA REMOVAL and correct to use FLUSH CACHE. My first reaction to FreeBSD use of MEDIA REMOVAL was: ``Huh?''. turns out to be a good thing :-) BTW, FreeBSD today, issues TEST DEVICE READY before an INQUIRY in conjunction with the PREVENT MEDIA REMOVAL upon open. This is fine except it is backwards to the standard. Especially where SCSI I devices are concerned. For example, it will promptly hang most CD-R devices when you ask them to do TEST READY on LUN other than zero. Disabling LUN handling works but akin to remove an infected organ. It sure cures the infection but can leave you physically chalenged. > As David F. has pointed out, the last close is happening and we are > waiting for it to complete, the only problem is that the timeout is > much too short for the "prevent/allow media removal" command. The > CAM code does some handwavy calculation based on the size of the > target disk so that if you have a multi-gigabyte "emulated disk", > the timeout will be larger than for a 4gig "normal disk". It uses > an explicit sync cache command though while keeping the media locking > command timeouts short (the unlock happens after the sync cache). The DPT driver logic for timeout is based on the caseload in the controller. It is just as hand waving and just as prone to failure. My opinion on timeouts is that they should do what we do today; Provide the HBA with a value and let it decide what to do with it. Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970714195439.Shimon>