On Sat, 2016-05-21 at 03:04 +0200, Axel Heider wrote: > > I wonder if there are any ideas how dm-crypto or LUKS can handle this > case. Or is the recommendation that the USB suspend should not happen > at all for devices that are broken (ie. that disconnect and reconnect > on resume)? > Even if all handles on /dev/sda are released internally, there is not > really a guarantee that the devices comes back as /dev/sda are the > disconnect/reconnect. However, the UUID should be the same, so that > could be used to detect it's the same device and partition then and > accesses get re-routed to it then transparently. I doubt if it could be done clean. Most targets in Device Mapper ask for careful unstacking. Red Hat (leading Linux vendor) still seems to be recommending that. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-si ngle/Storage_Administration_Guide/#removing_devices I would rather investigate the (flaky) USB device. First, does it happen only when Runtime PM is enabled ? If so, you should just blacklist it from Power Management. Many devices, under Linux, report (false) PM capabilities. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
