From mboxrd@z Thu Jan 1 00:00:00 1970 References: <20180102171034.GC26695@redhat.com> <20180103150713.GA16217@redhat.com> From: Eric Ren Message-ID: Date: Thu, 4 Jan 2018 17:06:10 +0800 MIME-Version: 1.0 In-Reply-To: <20180103150713.GA16217@redhat.com> Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: [linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="iso-8859-1"; format="flowed" To: LVM general discussion and development , David Teigland David, On 01/03/2018 11:07 PM, David Teigland wrote: > On Wed, Jan 03, 2018 at 11:52:34AM +0800, Eric Ren wrote: >>> 1. one one node: lvextend --lockopt skip -L+1G VG/LV >>> >>> That option doesn't exist, but illustrates the point that some new >>> option could be used to skip the incompatible LV locking in lvmloc= kd. >> Hmm, is it safe to just skip the locking while the LV is active on other >> node? >> Is there somewhere in the code to avoid concurrent lvm command to execute >> at the same time? > The VG lock is still used to protect the VG metadata change. The LV lock > doesn't protect anything per se, it just represents that lvchange has > activated the LV on this host. (The LV lock does not represent the > suspended/resumed state of the dm device either, as you suggested above.) I see, thanks for you explanation! > I'll send a simple patch to skip the lv lock to try this. I've tested your patch and it works very well.=C2=A0 Thanks very much. Regards, Eric