On 21.08.22 22:59, James Dutton 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. Arguably, in case ACPI tells us that the port is internal we ought to reintroduce that behavior. It is very much an edge case, though. >> 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. Basically like failover with multi path I'd say. > 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. We have three issues 1) Is this the same device? 2) Has it been altered while it was disconnected? 3) What do we do in case of memory pressure causing pages to be laundered? In case of device persistance we ignore #1 and #2 and #3 does not exist > 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 is strictly speaking not a USB question. Every device has this issue. You just do not check on resumption from S3 or S4whether somebody has replaced the SATA disk in your system. Regards Oliver
