[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dm-crypt
Subject:    Re: [dm-crypt] dm-crypt LUKS and USB power management
From:       Ritesh Raj Sarraf <rrs () researchut ! com>
Date:       2016-05-30 16:56:08
Message-ID: 1464626648.3187.12.camel () researchut ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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
["signature.asc" (application/pgp-signature)]

_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt


[prev in list] [next in list] [prev in thread] [next in thread]