From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 30 Mar 2011 23:03:08 +0200 (CEST) Message-ID: <4D939A88.70009@redhat.com> Date: Wed, 30 Mar 2011 23:03:04 +0200 From: Milan Broz MIME-Version: 1.0 References: <1301506184.6571.29.camel@occipital.ops.ut.us.attask.com> In-Reply-To: <1301506184.6571.29.camel@occipital.ops.ut.us.attask.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] shared block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Zabriskie Cc: dm-crypt@saout.de On 03/30/2011 07:29 PM, Michael Zabriskie wrote: > I have been able to gather that a shared block device type setup is not > supported. I.E. luks + clvm + gfs2, luks + asm, or luks + ocfs2 shared > across multiple servers. So what I am wondering is if this is on the > road map or if there is another open source technology out there that > can accomplish this? If you have LUKS device and mapped (plaintext) device is exported through iSCSI/DRBD or whatever to several cluster nodes, it will work (and use some clustered fs, or maybe clvmd on top of that). (IOW encryption run only on some master server.) What you cannot do is to map the underlying device on several nodes and run LUKS on every node separately (in parallel). (In principle, with proper barrier/flush support and clustered fs on top it, it should work but nobody tests and support these configurations.) Or you have to open exactly on one node and migrate it as service (similar to HA LVM mode). (That --non-exclusive option was to map one underlying device to several mappings on _one_ system, nothing to do with clustered system.) Anyway, what is the use case here? Milan