From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4doIsgjVsvmG for ; Mon, 18 Mar 2013 07:30:55 +0100 (CET) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 18 Mar 2013 07:30:54 +0100 (CET) Received: by mail-ia0-f175.google.com with SMTP id y26so2699732iab.34 for ; Sun, 17 Mar 2013 23:30:52 -0700 (PDT) MIME-Version: 1.0 From: ".. ink .." Date: Mon, 18 Mar 2013 02:30:31 -0400 Message-ID: Content-Type: multipart/alternative; boundary=14dae934100d67c85004d82d2134 Subject: [dm-crypt] an official way to know if the underlying device is gone for all supported volume formats List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --14dae934100d67c85004d82d2134 Content-Type: text/plain; charset=ISO-8859-1 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 --14dae934100d67c85004d82d2134 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
http://code.google.com/p/cryptsetup/sou= rce/detail?r=3Df64064fe71363a14ab0c62359e451f9cdc39dc50

The abov= e 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 9= 8 in the below source file to know.It would be nice if there was an officia= l way for all three types.

http://code.google.com/p/zulucrypt/source/brow= se/zuluCrypt-cli/bin/clear_dead_mappers.c
--14dae934100d67c85004d82d2134-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goehY7I1VPMi for ; Mon, 18 Mar 2013 23:02:41 +0100 (CET) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 18 Mar 2013 23:02:41 +0100 (CET) Received: by mail-ea0-f173.google.com with SMTP id h14so2705991eak.18 for ; Mon, 18 Mar 2013 15:02:38 -0700 (PDT) Message-ID: <51478EC4.4020006@gmail.com> Date: Mon, 18 Mar 2013 23:01:40 +0100 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] an official way to know if the underlying device is gone for all supported volume formats List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ".. ink .." Cc: dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFNhxdroP4vG for ; Tue, 19 Mar 2013 03:24:25 +0100 (CET) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 19 Mar 2013 03:24:24 +0100 (CET) Received: by mail-ie0-f172.google.com with SMTP id c10so7781896ieb.17 for ; Mon, 18 Mar 2013 19:24:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <51478EC4.4020006@gmail.com> References: <51478EC4.4020006@gmail.com> From: ".. ink .." Date: Mon, 18 Mar 2013 22:24:02 -0400 Message-ID: Content-Type: multipart/alternative; boundary=e89a8f3ba4c7b06af704d83dcd69 Subject: Re: [dm-crypt] an official way to know if the underlying device is gone for all supported volume formats List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz , dm-crypt@saout.de --e89a8f3ba4c7b06af704d83dcd69 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 18, 2013 at 6:01 PM, Milan Broz wrote: > > On 18.3.2013 7:30, .. ink .. wrote: > >> >> http://code.google.com/p/**cryptsetup/source/detail?r=** >> f64064fe71363a14ab0c62359e451f**9cdc39dc50 >> >> 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. --e89a8f3ba4c7b06af704d83dcd69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

On 18.3.2013 7:30, .. ink .. wrote:

http://code.google.com/p/= cryptsetup/source/detail?r=3Df64064fe71363a14ab0c62359e451f9cdc39dc50

=A0The 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<= br> 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 contradic= ting and unpredictable as it start to exhibit undocumented behaviors.

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

with PLAIN volume,"crypt_init_by_name" return 0 signifying su= ccess,but "crypt_get_device_name" returns NULL,an undocumented re= turn value so there is a real problem with underlying device disappearing w= ith PLAIN volumes as the return value if unchecked segfault the program.
There is another API i do not remember at the moment than return undocu= mented NULL in this situation.
=A0


--e89a8f3ba4c7b06af704d83dcd69-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc7kok2Qk4fG for ; Tue, 19 Mar 2013 07:23:26 +0100 (CET) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 19 Mar 2013 07:23:25 +0100 (CET) Received: by mail-ee0-f43.google.com with SMTP id c50so48130eek.2 for ; Mon, 18 Mar 2013 23:23:25 -0700 (PDT) Message-ID: <51480423.7040807@gmail.com> Date: Tue, 19 Mar 2013 07:22:27 +0100 From: Milan Broz MIME-Version: 1.0 References: <51478EC4.4020006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] an official way to know if the underlying device is gone for all supported volume formats List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mhogomchungu@gmail.com Cc: dm-crypt 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