Re: USB disk disconnect problems

[Alan Stern <stern@rowland.harvard.edu>]

On Sun, Aug 21, 2022 at 11:42:00AM -0700, Matthew Dharm wrote:
> On Sun, Aug 21, 2022 at 7:47 AM Alan Stern <stern@rowland.harvard.edu>
> wrote:
> 
> > On Sun, Aug 21, 2022 at 12:17:30PM +0100, James Dutton wrote:
> > > I know my suggested behaviour might be detrimental for some users, in
> > > case one modifies the usb disk in another computer and then comes
> > > back, but I would like an option that assumes it has not been plugged
> > > into anything else.
> 
> 
> In the “old days” (that is, my original design for use-storage) it used to
> do exactly what you are looking for - based on VID, DID, and SerialNumber
> it would “remember” devices. The SCSI host would never be destroyed, and
> when a device re-appeared it would be re-connected to the existing host.

Ah yes...  I do remember those days, but not very often.  :-)

> That caused all sorts of problems. The SCSI and block layers just couldn’t
> handle it well. A clean umount / mount cycle worked fine, but if you
> unexpectedly disconnected the device all hell broke loose and there was no
> way to recover.
> 
> I did it this way because, way back when, there were issues dynamically
> destroying SCSI hosts. The people who worked on those other layers found it
> much, much easier to fix that problem than try to make it possible to
> recover from an unexpected disconnect.
> 
> Honestly, I’m not even sure where you would need to begin to make this
> work. It would require pretty radical changes is the block I/O layers to
> differentiate different failure modes, keep a lot more data around after
> certain types of failures, allow for specifying which devices this new
> policy (which is assuming reconnected devices really haven’t been altered)
> applies to, etc — it’s a big lift.

Provided you don't mind giving up after 30 seconds (the default SCSI 
timeout), you wouldn't need to change the block or other layers.  All 
you would have to do is avoid reporting a command failure if the reason 
for the failure is disconnection, wait for the device to reappear, and 
then retry the command.  (Yes, there would be a few extra complications 
but that's the basic idea.)  As far as the SCSI or block layers are 
concerned, it would look like the I/O succeeded but took an unusually 
long time to complete.

Alan Stern