public inbox for lvm2-cvs@sourceware.org
help / color / mirror / Atom feed
From: wysochanski@sourceware.org
To: lvm-devel@redhat.com, lvm2-cvs@sourceware.org
Subject: LVM2/lib format_text/format-text.c metadata/me ...
Date: Mon, 28 Jun 2010 20:31:00 -0000	[thread overview]
Message-ID: <20100628203139.14218.qmail@sourceware.org> (raw)

CVSROOT:	/cvs/lvm2
Module name:	LVM2
Changes by:	wysochanski@sourceware.org	2010-06-28 20:31:39

Modified files:
	lib/format_text: format-text.c 
	lib/metadata   : metadata.c metadata.h 

Log message:
	Add mda_locns_match() internal library function for mapping pv/device to VG mda.
	
	A metadata_area is defined independent of the location.  One downside
	is that there is no obvious mapping from a pv to an mda.  For a PV in
	a VG, we need a way to start with a PV and end up with an MDA, if we
	are to manage mdas starting with a device/pv.  This function provides
	us a way to go down the list of PVs on a VG, and identify which ones
	match a particular PV.
	
	I'm not entirely happy with this approach, but it does fit into the
	existing structures in a reasonable way.
	
	An alternative solution might be to refactor the VG - PV interface such
	that mdas are a list tied to a PV.  However, this seemed a bit tricky since
	a PV does not come into existence until after the list of mdas is
	constructed (see _vg_read() - we create a 'fid' and attach mdas to it,
	then we go through them and attach pvs).
	
	Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
	Reviewed-by: Alasdair G Kergon <agk@redhat.com>

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/format_text/format-text.c.diff?cvsroot=lvm2&r1=1.128&r2=1.129
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.c.diff?cvsroot=lvm2&r1=1.347&r2=1.348
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.h.diff?cvsroot=lvm2&r1=1.206&r2=1.207

--- LVM2/lib/format_text/format-text.c	2010/06/28 20:31:18	1.128
+++ LVM2/lib/format_text/format-text.c	2010/06/28 20:31:38	1.129
@@ -121,6 +121,20 @@
 	return 0;
 }
 
+static unsigned _mda_locns_match_raw(struct metadata_area *mda1,
+				     struct metadata_area *mda2)
+{
+	struct mda_context *mda1c = (struct mda_context *) mda1->metadata_locn;
+	struct mda_context *mda2c = (struct mda_context *) mda2->metadata_locn;
+
+	if ((mda1c->area.dev == mda2c->area.dev) &&
+	    (mda1c->area.start == mda2c->area.start) &&
+	    (mda1c->area.size == mda2c->area.size))
+		return 1;
+
+	return 0;
+}
+
 /*
  * For circular region between region_start and region_start + region_size,
  * back up one SECTOR_SIZE from 'region_ptr' and return the value.
@@ -1732,6 +1746,7 @@
 	.mda_total_sectors = _mda_total_sectors_raw,
 	.mda_in_vg = _mda_in_vg_raw,
 	.pv_analyze_mda = _pv_analyze_mda_raw,
+	.mda_locns_match = _mda_locns_match_raw
 };
 
 /* pvmetadatasize in sectors */
--- LVM2/lib/metadata/metadata.c	2010/06/28 20:30:14	1.347
+++ LVM2/lib/metadata/metadata.c	2010/06/28 20:31:38	1.348
@@ -3855,6 +3855,36 @@
 	return pv_field(pv, pe_alloc_count);
 }
 
+/*
+ * This function provides a way to answer the question on a format specific
+ * basis - does the format specfic context of these two metadata areas
+ * match?
+ *
+ * A metatdata_area is defined to be independent of the underlying context.
+ * This has the benefit that we can use the same abstraction to read disks
+ * (see _metadata_text_raw_ops) or files (see _metadata_text_file_ops).
+ * However, one downside is there is no format-independent way to determine
+ * whether a given metadata_area is attached to a specific device - in fact,
+ * it may not be attached to a device at all.
+ *
+ * Thus, LVM is structured such that an mda is not a member of struct
+ * physical_volume.  The location of the mda depends on whether
+ * the PV is in a volume group.  A PV not in a VG has an mda on the
+ * 'info->mda' list in lvmcache, while a PV in a VG has an mda on
+ * the vg->fid->metadata_areas list.  For further details, see _vg_read(),
+ * and the sequence of creating the format_instance with fid->metadata_areas
+ * list, as well as the construction of the VG, with list of PVs (comes
+ * after the construction of the fid and list of mdas).
+ */
+unsigned mda_locns_match(struct metadata_area *mda1, struct metadata_area *mda2)
+{
+	if (!mda1->ops->mda_locns_match || !mda2->ops->mda_locns_match ||
+	    mda1->ops->mda_locns_match != mda2->ops->mda_locns_match)
+		return 0;
+
+	return mda1->ops->mda_locns_match(mda1, mda2);
+}
+
 unsigned mda_is_ignored(struct metadata_area *mda)
 {
 	return (mda->flags & MDA_IGNORED);
--- LVM2/lib/metadata/metadata.h	2010/06/28 20:30:14	1.206
+++ LVM2/lib/metadata/metadata.h	2010/06/28 20:31:38	1.207
@@ -156,6 +156,12 @@
 	int (*pv_analyze_mda) (const struct format_type * fmt,
 			       struct metadata_area *mda);
 
+	/*
+	 * Do these two metadata_areas match with respect to their underlying
+	 * location?
+	 */
+	unsigned (*mda_locns_match)(struct metadata_area *mda1,
+				    struct metadata_area *mda2);
 };
 
 #define MDA_IGNORED 0x00000001
@@ -169,6 +175,7 @@
 
 unsigned mda_is_ignored(struct metadata_area *mda);
 void mda_set_ignored(struct metadata_area *mda, int value);
+unsigned mda_locns_match(struct metadata_area *mda1, struct metadata_area *mda2);
 
 #define seg_pvseg(seg, s)	(seg)->areas[(s)].u.pv.pvseg
 #define seg_dev(seg, s)		(seg)->areas[(s)].u.pv.pvseg->pv->dev


             reply	other threads:[~2010-06-28 20:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-28 20:31 wysochanski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-06-29 22:37 wysochanski
2010-06-28 20:35 wysochanski
2010-06-28 20:32 wysochanski
2005-04-17 23:57 agk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100628203139.14218.qmail@sourceware.org \
    --to=wysochanski@sourceware.org \
    --cc=lvm-devel@redhat.com \
    --cc=lvm2-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).