From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 3 Jan 2018 09:07:13 -0600 From: David Teigland Message-ID: <20180103150713.GA16217@redhat.com> References: <20180102171034.GC26695@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: 7bit To: Eric Ren , linux-lvm@redhat.com 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 lvmlockd. > > 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'll send a simple patch to skip the lv lock to try this. Dave