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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
