All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/3] Add infrastructure for cleaner pv handling, v2
@ 2010-03-17 15:51 Dave Wysochanski
  2010-03-17 15:51 ` [PATCH 1/3] Add a couple of lvmcache functions to aid in lookups by pvname Dave Wysochanski
  0 siblings, 1 reply; 6+ messages in thread
From: Dave Wysochanski @ 2010-03-17 15:51 UTC (permalink / raw)
  To: lvm-devel


This is the second version of the patchset that adds infrastructure
to move us more towards the goal of removing the standalone PV object.

>From now on, a get/set of a PV property from the pvname requires
a lookup of the vgname, then a vg handle from the vgname, a
pv from the vg handle, and finally using the pv handle to get/set
the property.

The last patch reworks pvchange to use this new functionality.
It passes the testsuite but does have at least one bug.  A
setup with a VG containing a PV with metadatacopies == 0 and
pvchange -u --all end up failing because the PV is on both the
orphan VG and the real VG.  I tried a few ways of working around
this, including processing the non-orphan VGs first, but I believe
the root problem lies in the vg locking and lvmcache.
The lvmcache gets invalidated after each vg lock change, so even
if a PV with metadata copies was known to be in a real VG, once
that lock is dropped the cache is invalidated and the PV shows up
in the vg->pvs list for the orphan VG.



^ permalink raw reply	[flat|nested] 6+ messages in thread
* [PATCH 0/3] Add infrastructure for cleaner pv handling
@ 2010-02-13  0:51 Dave Wysochanski
  2010-02-13  0:51 ` [PATCH 1/3] Add a couple of lvmcache functions to aid in lookups by pvname Dave Wysochanski
  0 siblings, 1 reply; 6+ messages in thread
From: Dave Wysochanski @ 2010-02-13  0:51 UTC (permalink / raw)
  To: lvm-devel


This patchset adds some infrastructure to move us more towards the
goal of removing the standalone PV object.

>From now on, a user that wants to get/set a PV property and
knows only the pvname must first lookup the vgname, then obtain
a vg handle, and finally use the pv handle to get/set the property.

The last patch reworks pvchange to use this new functionality.
It passes the testsuite but does still have one bug.  A
setup with a VG containing a PV with metadatacopies == 0 and
pvchange -u --all end up failing because the PV is on both the
orphan VG and the real VG.  I think this is a bug internally
unrelated to this patchset but I have yet to track it down.
It should be fixed before we move the tools to this new method.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-03-17 16:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-17 15:51 [PATCH 0/3] Add infrastructure for cleaner pv handling, v2 Dave Wysochanski
2010-03-17 15:51 ` [PATCH 1/3] Add a couple of lvmcache functions to aid in lookups by pvname Dave Wysochanski
2010-03-17 15:51   ` [PATCH 2/3] Add find_vgname_from_pvname() function using lvmcache functions Dave Wysochanski
2010-03-17 15:51     ` [PATCH 3/3] Update pvchange to always obtain a vg handle for each pv to process Dave Wysochanski
2010-03-17 16:50     ` [PATCH 2/3] Add find_vgname_from_pvname() function using lvmcache functions Dave Wysochanski
  -- strict thread matches above, loose matches on Subject: below --
2010-02-13  0:51 [PATCH 0/3] Add infrastructure for cleaner pv handling Dave Wysochanski
2010-02-13  0:51 ` [PATCH 1/3] Add a couple of lvmcache functions to aid in lookups by pvname Dave Wysochanski
2010-02-13  0:51   ` [PATCH 2/3] Add find_vgname_from_pvname() function using lvmcache functions Dave Wysochanski

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.