cvs commit: src/sys/cam/scsi scsi_da.c

[Nate Lawson]

mjacob at freebsd.org wrote:
>>>
>>>  From a silly semantic point of view to get around this, we should 
>>> still support and require SYNC_CACHE on close except where devices 
>>> don't support it (and any device that hangs on a SYNC_CACHE doesn't 
>>> support it- period).
>>
>> The problem is that we don't know if the device will misbehave until it
>> does, and then we don't know if we can reliably recover it.
> 
> This is back to what I referred to earlier by a week or so- booting 
> installation (or as a fallback) with a pessimization flag that avoids 
> all questionable commands until the system is up enough to load (via 
> firmware(9) or sysctl or rc scripts) better information.

That wouldn't work in this case since you would need to tell GEOM not to 
look at certain devices (just another quirk list).

>>> On detach, devices that still need to have data commited via an 
>>> opcode that looks remarkably like SYNC_CACHE can and should have that 
>>> happen- with all the infrastructure changes that go along with 
>>> allowing devices to be detached (w/o complaint) with a live command.
>>
>> What instigates this problem is that the GEOM layer will open the 
>> device, read a few sectors, close it, then do that again a few more 
>> times, long before the user tries to mount/unmount it.  It's the whole 
>> GEOM-taste thing where it tries to essentially auto-probe the storage. 
>> When we unconditionally send a SYNC_CACHE in daclose(), the 
>> misbehaving device is dead long before the user has a chance to do 
>> anything.  One hack might be to track if any write command were done 
>> while the device was open, and only issue the SYNC_CACHE if so. Since 
>> the GEOM tasting will only read, it'll pass this test and avoid the 
>> problem.
> 
> It's not a hack to keep track of a write commands- after all, I did 
> exactly this for SunOS 4.1 (or was it 4.0?) to know whether you'd 
> dirtied the device or not- and of course *I* would be believe it to 
> still be perfect, eh? :-)
> 
> This would be an excellent and cheap idea to implement and I think I'll 
> do so. I bet you that this will take care of nearly all of the boot time 
> issues.

That's fine, but you'd also have to track things like MODE SELECT or 
COPY or FORMAT or other commands that might actually dirty the media 
without being a WRITE.

I don't see why GEOM can't open the device read-only to do its probe. 
Doesn't it use a device vnode?

-- 
Nate