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

[mjacob at freebsd.org]

>>
>>  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.

>
>> 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.