duplicate pv names

duplicate pv names

[David Teigland]

My current patch set it having a problem with the test vgimportclone.sh,
which has me questioning the desired pvs output with duplicate pv names.

# dd if=/dev/sdc2 of=/dev/sdc3 bs=256K count=1

# pvs
  Found duplicate PV mPJxALsM0WGwdEZfoE7ewO8inDs1EhyG: using /dev/sdc3 not /dev/sdc2
  PV         VG           Fmt  Attr PSize   PFree  
  /dev/sdc1  vgu          lvm2 a--   32.00g  23.00g
  /dev/sdc3  vgv          lvm2 a--   16.00m  16.00m
  /dev/sdc4  vgv          lvm2 a--   16.00m  16.00m

Do we want to omit /dev/sdc2 from this list?  (Suggest no.)

# pvs -a
  Found duplicate PV mPJxALsM0WGwdEZfoE7ewO8inDs1EhyG: using /dev/sdc3 not /dev/sdc2
  PV                     VG           Fmt  Attr PSize   PFree  
  /dev/sdc1              vgu          lvm2 a--   32.00g  23.00g
  /dev/sdc3              vgv          lvm2 a--   16.00m  16.00m
  /dev/sdc3              vgv          lvm2 a--   16.00m  16.00m
  /dev/sdc4              vgv          lvm2 a--   16.00m  16.00m

Do we want /dev/sdc3 to appear twice, or one of them to be /dev/sdc2, or
omit one like above?  (Suggest both sdc2 and sdc3 appear.)

# pvs /dev/sdc2
  Found duplicate PV mPJxALsM0WGwdEZfoE7ewO8inDs1EhyG: using /dev/sdc3 not /dev/sdc2
  PV         VG   Fmt  Attr PSize  PFree 
  /dev/sdc3  vgv  lvm2 a--  16.00m 16.00m

# pvs /dev/sdc3
  Found duplicate PV mPJxALsM0WGwdEZfoE7ewO8inDs1EhyG: using /dev/sdc2 not /dev/sdc3
  PV         VG   Fmt  Attr PSize  PFree 
  /dev/sdc2  vgv  lvm2 a--  16.00m 16.00m

It seems strange that we use the duplicate that was *not* specified.
Is that what we want?  (Suggest it be reversed.)

duplicate pv names

[Petr Rockai]

Hi,

David Teigland <teigland@redhat.com> writes:
> My current patch set it having a problem with the test vgimportclone.sh,
> which has me questioning the desired pvs output with duplicate pv names.

I ran into similar problems with a different set of patches, that remove
pv_read. What I'll probably need to do is adding a list of devices to
PVs, so we can check whether something on the command line matches any
of the "duplicate" PVs.

I see you make quite heavy use of pv_read in your new version of
process_each_pv. You can have a look at:

(git clone) http://repos.mornfall.net/lvm2/mornfall.git

branch "merged" or for more limited view of the pv_read removal patches,
branch "lvmcache". (git checkout origin/merged).

It would be good if we could get rid of pv_read, as the code for
handling nomda PVs is wrong anyway, and we always need to scan. I think
the only remaining issue with the non-pv_read version is the duplicate
handling as outlined above.

Petr

-- 
id' Ash = Ash; id' Dust = Dust; id' _ = undefined

duplicate pv names

[David Teigland]

On Wed, Apr 03, 2013 at 11:32:06AM +0200, Petr Rockai wrote:
> I ran into similar problems with a different set of patches, that remove
> pv_read. What I'll probably need to do is adding a list of devices to
> PVs, so we can check whether something on the command line matches any
> of the "duplicate" PVs.
> 
> I see you make quite heavy use of pv_read in your new version of
> process_each_pv. You can have a look at:
> 
> (git clone) http://repos.mornfall.net/lvm2/mornfall.git
> 
> branch "merged" or for more limited view of the pv_read removal patches,
> branch "lvmcache". (git checkout origin/merged).

I wish I'd known you were also working on toollib.c; we could have
coordinated the sequence of changes a little better.  Perhaps we could
all push our in-progress work to an lvm2.git branch like I've done in
http://git.fedorahosted.org/cgit/lvm2.git/log/?h=dev-dct-process-each

> It would be good if we could get rid of pv_read, as the code for
> handling nomda PVs is wrong anyway, and we always need to scan. I think
> the only remaining issue with the non-pv_read version is the duplicate
> handling as outlined above.

OK, it'll be nice to get rid of the nomda case.  I'll study your changes
further and try to rework my new process_each_pv to avoid using pv_read.
Perhaps you'll then be able to drop the toollib commit in your tree.