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

[Scott Long]

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.

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

Scott