Re: [dm-crypt] an official way to know if the underlying device is gone for all supported volume formats

[Milan Broz <gmazyland@gmail.com>]

On 18.3.2013 7:30, .. ink .. wrote:
>
> http://code.google.com/p/cryptsetup/source/detail?r=f64064fe71363a14ab0c62359e451f9cdc39dc50
>
>  The above commit log speaks of LUKS volumes,what about plain and
> cryptsetup volumes? The return code for LUKS is vague too since the
> log is not clear.

plain device doesn't have this problem, it initializes completely from
mapping table (no real problem if underlying device disappeared).

> I remember asking a way to know if the underlying devise is gone but
> my request went unaswered,i therefore use the following hack in line
> 97 and 98 in the below source file to know.It would be nice if there
> was an official way for all three types.

But it is not cryptsetup job. libcryptsetup just need to cope with situation
when underlying device disappear and "handle" it reliably.

(Plain a LUKS is fundamentally different here - for plain you do not need
to read underlying device at all to initialise context but for
LUKS you need read LUKS header from underlying device.)

The only reliable way to properly track all situations when device
disappears I know is to listen udev events and react to remove event
(as e.g. udisks does).
Cryptsetup cannot do that, it has no running daemon which can listen
to these events.

Device "disappears" can mean many things. it can be intermittent (temporary)
or persistent problem (no reliable way to distinguish between these!)
Just to illustrate the problem, imagine these situations (every such situation
can behave slightly differently for userspace)

- raid device lost more members it can handle (degraded->failed)
- device node was removed (forced udev event) (but device itself is fine)
- usb device was removed, but still in use (mounted fs etc)
- network block device (iSCSI, nbd, DRBD, ...) is not responding (netword glitch)
or remote device failed
- device was put to offline mode (echo "offline" > /proc/....)
- underlying device-mapper device was remmaped to another device or error target
- disc controller failure (hard reset)
- disc itself crashed, not responding, randomly failing requests
- size of underlying device is (temporarily) 0
  (was seen in some enterprise disk arrays during reconfiguration)
- multipath device lost all paths
... and many others

The Linux storage stack can be very complicated and it is in general... a true mess :-)

Milan