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
next 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: linkBe 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).