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

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

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

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.

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.

http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/bin/clear_dead_mappers.c

[-- Attachment #2: Type: text/html, Size: 827 bytes --]

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

[Milan Broz]

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

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

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On Mon, Mar 18, 2013 at 6:01 PM, Milan Broz <gmazyland@gmail.com> wrote:

>
> On 18.3.2013 7:30, .. ink .. wrote:
>
>>
>> http://code.google.com/p/**cryptsetup/source/detail?r=**
>> f64064fe71363a14ab0c62359e451f**9cdc39dc50<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).
>
> and what about truecrypt volume?
The point is that when the underlying device is gone,the API becomes
contradicting and unpredictable as it start to exhibit undocumented
behaviors.

if "crypt_init_by name" return non zero when the underlying device is gone
with LUKS volumes,it should return the same non zero value when the
underlying device is gone for both PLAIN and TRUECRYPT volume.

with PLAIN volume,"crypt_init_by_name" return 0 signifying success,but
"crypt_get_device_name" returns NULL,an undocumented return value so there
is a real problem with underlying device disappearing with PLAIN volumes as
the return value if unchecked segfault the program.

There is another API i do not remember at the moment than return
undocumented NULL in this situation.

[-- Attachment #2: Type: text/html, Size: 1964 bytes --]

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

[Milan Broz]

On 19.3.2013 3:24, .. ink .. wrote:
> and what about truecrypt volume? The point is that when the
> underlying device is gone,the API becomes contradicting and
> unpredictable as it start to exhibit undocumented behaviors.

No, crypt_get_type() should return NULL in this case ("unknown").
This is documented value.

...
> There is another API i do not remember at the moment than return
> undocumented NULL in this situation.

For unknown type the query operations are not defined (resp. you get NULL)
because itnerenaly it is is nor (yet) recognised.

But yes, it should be probably unified and documented better (NULL
seems to missing in doc in some query commands).
(In fact, underlying device cannot disapper if in use - there is still
(in kernel) some reference used in maping table but userspace behaves
diferently seems.)

Milan