Date: Sun, 13 Jul 1997 18:37:52 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: dg@root.com Cc: Simon Shapiro <Shimon@i-Connect.Net>, filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Subject: Re: problems with reboot Message-ID: <199707140037.SAA02750@pluto.plutotech.com> In-Reply-To: Your message of "Sun, 13 Jul 1997 16:47:48 PDT." <199707132347.QAA00548@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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. 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). >-DG > >David Greenman >Core-team/Principal Architect, The FreeBSD Project -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707140037.SAA02750>