From: wysochanski@sourceware.org <wysochanski@sourceware.org>
To: lvm-devel@redhat.com
Subject: LVM2/lib/metadata metadata-exported.h metadata.c
Date: 19 May 2010 11:52:38 -0000 [thread overview]
Message-ID: <20100519115238.25069.qmail@sourceware.org> (raw)
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: wysochanski at 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
next reply other threads:[~2010-05-19 11:52 UTC|newest]
Thread overview: 17+ 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 LVM2/lib/metadata metadata-exported.h metadata.c 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-06-09 14:59 ` Petr Rockai
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 \
/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 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.