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 3xUuHqKRQ90R for ; Fri, 30 Aug 2013 07:29:59 +0200 (CEST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 30 Aug 2013 07:29:59 +0200 (CEST) Received: by mail-ea0-f176.google.com with SMTP id q16so663772ead.21 for ; Thu, 29 Aug 2013 22:29:58 -0700 (PDT) Message-ID: <52202DD1.4040808@gmail.com> Date: Fri, 30 Aug 2013 07:29:53 +0200 From: Milan Broz MIME-Version: 1.0 References: <1377358818.1313.21.camel@ryx.lan> <20130826082310.GA10172@citd.de> <521EE10F.4040602@gmail.com> <20130829231605.GA25013@citd.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] u?mount (8) helper script for luks encrypted disks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ".. ink .." Cc: "dm-crypt@saout.de" Well, if you want use such mount helper script, you can. But I do no think this should be part of upstream package. On 30.8.2013 1:56, .. ink .. wrote: > On unmounting. > 1. Look at the path to be unmounted,if it starts with "/dev/mapper/" > then it could an mdraid path or a cryptsetup mapper path or > something else.Its easy to check which one is it. Nope. You have /dev/VG/LV or /dev/mpath/NAME (aka friendly mpath names) etc. These are symlinks, or on non-udev system directly device nodes. If you want to check for dm device, you should check for major number of device. Ditto for MD (note md can be some fake raid as well as replacement for dmraid.) In shell script, I would use lsblk to detect it (that should have all "known" tricks included :) > 2. If its > encrypted mapper path,then unmount the mapper and then call > cryptsetup to unmap the mapper.If its not encrypted then just > unmount. Not sure if it works for lazy umount (device is still in use). Also udev can perform blkid "scan on close" blocking the device but this one problem should be already solved inside libdevmapper (retrying removal). Milan