[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