[lvm-devel] [PATCH 16/17] Fix pvchange -u to work with recent changes in metadata handling interface.

Peter Rajnoha prajnoha at redhat.com
Mon Jan 24 16:04:17 UTC 2011


On 01/24/2011 12:04 PM +0100, Peter Rajnoha wrote:
> I use PV id as a key for format instance's metadata_areas_index.
> But since we change this one, I still need to work with the original
> one to access the metadata areas (e.g. in pv_write). So, I defined
> the pv->old_id to store that.

One more thing to note. We should probably allow writing non-orphan
PVs directly... The pv_write code calls:

    /* Add a new cache entry with PV info or update existing one. */
        if (!(info = lvmcache_add(fmt->labeller, (const char *) &pv->id,   
                        pv->dev, FMT_TEXT_ORPHAN_VG_NAME, NULL, 0)))
                return_0;

..that changes any existing cache entry to be "orphaned", even if that
PV is already part of a VG!

The code concerned is in outer pv_write fn that calls format specific
pv_write code:

        if (!is_orphan_vg(pv->vg_name) || pv->pe_alloc_count) {
                log_error("Assertion failed: can't _pv_write non-orphan PV "
                          "(in VG %s)", pv->vg_name);
                return 0;
        }

Also, the pvchange -u call is not quite nice today:


          pv->vg_name = pv->fmt->orphan_vg_name;
          pv->pe_alloc_count = 0;
          if (!(pv_write(cmd, pv))) {
                      log_error("pv_write with new uuid failed "
                                          "for %s.", pv_name);
                      goto out;
          }
          pv->vg_name = orig_vg_name;
          pv->pe_alloc_count = orig_pe_alloc_count;


To support calling pv_write on non-orphan PVs, we need to destroy
the old cache item and insert a new one or just update the existing
cache entry. But since the pvid is used as a key to cache pvid hash,
we need to update this entry as well... But I don't see that as a
problem. The change is quite easy, the question is whether it won't
cause any other problems...

Peter




More information about the lvm-devel mailing list