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

[Nate Lawson]

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.

As long as it's specific to a known external device (USB), and the user 
knows that running some command (device_eject umass0) will make sure 
it's safe, I'm ok.

>> 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). 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.
> 
> Or have I missed something it what you're suggesting?

Actually, that's a different idea I had where you set a timeout() before 
running SYNC_CACHE, then cancel the command if it hangs.  Not sure how 
to implement the idea of a cancellable device call but maybe by creating 
a temporary thread?

-- 
Nate