On Sun, Aug 21, 2022 at 2:00 PM James Dutton <james.dutton@xxxxxxxxx> wrote: > > On Sun, 21 Aug 2022 at 21:03, Matthew Dharm > <mdharm-usb@xxxxxxxxxxxxxxxxxx> wrote: > > > > 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. > > > > 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. > > Are there any situations where we should actually try to recover? > What about: > The OS has not needed to read/write to the disk in a while. The USB > disk idles out and goes into a power save mode by itself. > The OS then wishes to write something, but would need to go through > some sort of wake up procedure first. > > I don't know if that is a state that is available for USB devices, but > if it was, would it be fair to try and recover? That scenario already happens all the time; rotating disks often spin-down after an idle period and then automatically spin-up at the next media-access command. So long as they spin-up within the command timeout (typically 30 seconds), there is no issue. BUT, this is very different from what you originally asked about -- in a low-power spin-down state, the USB interface is still connected; only the rotating has stopped. From the computer's perspective, the device has always remained attached; the only anomaly is that a command takes longer-than-usual to complete. The next level of deeper power savings would be a system-wide suspend / resume, which we've already discussed and is a path which is already handled (and also different from the original scenario you described). Matt -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux
