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/metadata metadata-exported.h metadata.c
Date: Wed, 19 May 2010 11:52:00 -0000	[thread overview]
Message-ID: <20100519115238.25069.qmail@sourceware.org> (raw)

CVSROOT:	/cvs/lvm2
Module name:	LVM2
Changes by:	wysochanski@sourceware.org	2010-05-19 11:52:38

Modified files:
	lib/metadata   : metadata-exported.h metadata.c 

Log message:
	Add find_vgname_from_{pvname|pvid} functions.
	
	Some commands start with a pvname, but we'd like to force users to
	start with a vg handle to obtain a pv handle.  Our best option seems
	to be providing a way to look up the vgname from the pvname, and then
	require them to use vg_read/vg_open.
	
	In addition to the pvname lookup function, this patch also provides a
	lookup by pvid.  The lookup by pvid can be used in conjunction with
	lvmcache_get_pvids to process all pvs in the system.
	
	The pvid find function first calls lvmcache_vgname_from_pvid, which may
	cause the label to be read if it is not in the cache.  If the vgname is
	returned is an orphan, we then check to see if there are metadata areas,
	and if not, we scan every PV on the system by calling scan_vgs_for_pvs().
	In most cases we should not need to do this, and by using the info->mdas
	count, we avoid calling pv_read() as prior code did.  So this patch is a
	bit cleaner and should allow us to refactor more of the pv code.
	
	Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata-exported.h.diff?cvsroot=lvm2&r1=1.145&r2=1.146
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.c.diff?cvsroot=lvm2&r1=1.342&r2=1.343

--- LVM2/lib/metadata/metadata-exported.h	2010/05/19 02:08:51	1.145
+++ LVM2/lib/metadata/metadata-exported.h	2010/05/19 11:52:37	1.146
@@ -625,6 +625,10 @@
 struct physical_volume *find_pv_by_name(struct cmd_context *cmd,
 					const char *pv_name);
 
+const char *find_vgname_from_pvname(struct cmd_context *cmd,
+				    const char *pvname);
+const char *find_vgname_from_pvid(struct cmd_context *cmd,
+				  const char *pvid);
 /* Find LV segment containing given LE */
 struct lv_segment *first_seg(const struct logical_volume *lv);
 
--- LVM2/lib/metadata/metadata.c	2010/05/19 02:36:33	1.342
+++ LVM2/lib/metadata/metadata.c	2010/05/19 11:52:37	1.343
@@ -3110,6 +3110,52 @@
 	return NULL;
 }
 
+
+const char *find_vgname_from_pvid(struct cmd_context *cmd,
+				  const char *pvid)
+{
+	char *vgname;
+	struct lvmcache_info *info;
+
+	vgname = lvmcache_vgname_from_pvid(cmd, pvid);
+
+	if (is_orphan_vg(vgname)) {
+		if (!(info = info_from_pvid(pvid, 0))) {
+			return_NULL;
+		}
+		/*
+		 * If an orphan PV has no MDAs it may appear to be an
+		 * orphan until the metadata is read off another PV in
+		 * the same VG.  Detecting this means checking every VG
+		 * by scanning every PV on the system.
+		 */
+		if (!dm_list_size(&info->mdas)) {
+			if (!scan_vgs_for_pvs(cmd)) {
+				log_error("Rescan for PVs without "
+					  "metadata areas failed.");
+				return NULL;
+			}
+		}
+		/* Ask lvmcache again - we may have a non-orphan name now */
+		vgname = lvmcache_vgname_from_pvid(cmd, pvid);
+	}
+	return vgname;
+}
+
+
+const char *find_vgname_from_pvname(struct cmd_context *cmd,
+				    const char *pvname)
+{
+	const char *pvid;
+
+	pvid = pvid_from_devname(cmd, pvname);
+	if (!pvid)
+		/* Not a PV */
+		return NULL;
+
+	return find_vgname_from_pvid(cmd, pvid);
+}
+
 /**
  * pv_read - read and return a handle to a physical volume
  * @cmd: LVM command initiating the pv_read


             reply	other threads:[~2010-05-19 11:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 11:52 wysochanski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-06-29 22:41 wysochanski
2010-06-28 20:36 wysochanski
2010-04-13 17:26 wysochanski
2009-07-26  2:02 wysochanski
2009-07-26  1:53 wysochanski
2009-07-15 17:26 agk
2009-07-15  6:10 mornfall
2009-07-10 21:19 wysochanski
2009-07-08 14:31 wysochanski
2009-07-08 14:28 wysochanski
2009-06-09 14:29 wysochanski
2009-01-27  1:48 agk
2009-01-27  0:40 agk
2009-01-26 22:13 agk
2008-03-13 22:51 wysochanski

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=20100519115238.25069.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).