Re: Flames over -- Re: Which is simpler?

[Phillip Susi <psusi@cfl.rr.com>]

Kyle Moffett wrote:
> No, that's _exactly_ what the spec says (well, not verbatim but close 
> enough).  When you disconnect, both the master and slave devices are 
> perfectly free to assume that the connection is completely broken and no 
> state is maintained.  Anything that breaks that assumption is against 
> the spec and likely to break in odd scenarios.

Perfectly free to != required to.  When you know that the connection is 
"broken" due to suspend and there is no way to differentiate between 
that and the device really being disconnected, you have two choices:

1) Assume the user is a masochistic idiot and replaced the device with 
one that looks just like it, or connected the device somewhere else and 
modified it before replacing it, or

2) Assume the user is sane and did no such thing.

Assumption #2 will be correct most of the time and is a valid use case, 
the first is not. If either assumption is wrong, it will lead to data 
loss.  All else being equal, which case do you optimize for?  The common 
and correct case, or the uncommon error case?

> Which causes worse data-loss, writing out cached pages and filesystem 
> metadata to a filesystem that has changed in the mean-time (possibly 
> allocating those for metadata, etc) or forcibly unmounting it as though 
> the user pulled the cable?  Most filesystems are designed to handle the 
> latter (it's the same as a hard-shutdown), whereas _none_ are designed 
> to handle the former.

So you condemn the common correct use case to always suffer data loss to 
give _slightly_ better protection to the uncommon and incorrect use 
case?  I think most users prefer a system that works right when you use 
it right to one that doesn't break quite as badly when you do something 
stupid.

Also why is this argument more valid for USB than SCSI?  I am just as 
free to unplug a scsi disk and replace it with a different one while 
hibernated, yet I don't suffer data loss when I don't do such 
foolishness.  By your argument, because the kernel can not know for sure 
that I didn't do that, it must disconnect and break all the drives on 
the bus.

> A good set of suspend scripts should handle the hardware-suspend with no 
> extra work because hardware supporting hardware-suspend basically 
> inevitably supports USB low-power-mode, and handle software-suspend by 
> either forcibly syncing and unmounting USB filesystems or by failing the 
> suspend and asking the user to.  You also could patch the kernel to fail 
> a powerdown software suspend if some USB device is mounted or otherwise 
> unremovably in-use.

That would prevent data loss, so it would be better than the current 
method of silently loosing data because you assume the user is out to 
get you.  There are other downsides to it though.  What if someone wants 
to boot from a usb drive and suspend to disk?

> Except that would make Linux broken with respect to the USB spec.  It is 

Please point out where in the USB spec it states that the OS _MUST_ 
assume that the device is no longer the same after a bus shutdown and 
restart, even though it otherwise appears to be.

> fallacious to assume that a USB device that the kernel has told to 
> disconnect will still have the same state when the kernel tries to 
> reconnect, even _if_ you could reliably identify it (which you can't 
> because there is no serial number of any sort on a lot of devices.

It is worse to assume that it HAS changed, when that is guaranteed to 
lead to data loss even though it most likely has not changed.  This is 
no different than assuming that the user knows what they are doing when 
they fdisk a drive.  You don't refuse to fdisk a drive just because you 
can't be 100% certain that they aren't doing something stupid that _may_ 
result in data loss, so you assume they know what they are doing and do 
as they say.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/