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 P9FW_AXcxmEF for ; Thu, 29 Nov 2012 14:52:32 +0100 (CET) Received: from awesome.dsw2k3.info (awesome.dsw2k3.info [IPv6:2a01:198:661:1f::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 29 Nov 2012 14:52:31 +0100 (CET) Date: Thu, 29 Nov 2012 14:43:13 +0100 From: Matthias Schniedermeyer Message-ID: <20121129134313.GA14313@citd.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] force luksClose List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Eberhardt Cc: dm-crypt@saout.de On 29.11.2012 14:02, Benjamin Eberhardt wrote: > Dear dm-crypt developers, > > since a while I am using dm-crypt with luks on usb-attached external > harddisks. Sometimes the usb connection breaks down and the harddisks > get reconnected under different device names. It is then impossible to > unmount (the "regular" way) and luksClose the "old" device which is > still active. For unmounting i can use the "-l" "lazy" switch to kind > of force unmounting of the luks'ed filesystem even though it is still > "busy". A luksClose of the device although is impossible and the only > way i know so far is to reboot the machine. Is it possible to > implement some kind of lazy luksClose so that "dead" devices of which > the physical layer has dissappeared can be removed? 1: Details 2: Works For Me When the partition is `umount`able, IOW no program is accessing a file on the mount and nothing has a CWD inside the mount. I can umount such a mount-point without problems. Linux "recognizes" somehow when the backing-store is vanished and just does the umount. Afterwards the loopaesClose(in my Case) also just works. Only when you have anything that holds the mountpoint open, there is a problem. But that's a case for fuser/lsof and/or making sure that nothing like NFS prevents the mountpoint from being destroyed. IOW. It's a problem of finding the culprit who holds the mountpoint open. -- Matthias