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

[Nate Lawson]

Scott Long wrote:
> mjacob at freebsd.org wrote:
>>
>>> I think Windows actually never runs SYNC_CACHE unless you select 
>>> "detach device".
>>
>> Maybe for pluggable devices, but otherwise Windows uses SYNC_CACHE and 
>> FUA quite freely (and correctly).
>>
>> I'm uncomfortable with the notion that there is uncommitted data 
>> present in a device after a close that can be lost due to power 
>> lossage (or unpluggage). From a user application or filesystem point 
>> of view, this is an axiom violation that no OS should ever allow.
>>
>>  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.

Right.  And at the moment, basically the command response polls forever. 
  Sometimes, if you unplug the device, the USB intr wakes things up and 
you can recover.

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

Right.  Shouldn't it be opening it read-only anyway?

-- 
Nate