From: Dave Wysochanski <dwysocha@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH 5/5] Add pv->vg to solidify link between a pv and a vg.
Date: Tue, 06 Apr 2010 09:48:29 -0400 [thread overview]
Message-ID: <1270561709.16846.6.camel@f10-node1> (raw)
In-Reply-To: <20100406132756.GE30760@agk-dp.fab.redhat.com>
On Tue, 2010-04-06 at 14:27 +0100, Alasdair G Kergon wrote:
> On Mon, Apr 05, 2010 at 03:51:39PM -0400, Dave Wysochanski wrote:
> > +++ b/lib/metadata/metadata-exported.h
> > @@ -184,6 +184,7 @@ struct physical_volume {
> > const char *vg_name;
> > struct id vgid;
> >
> > + struct volume_group *vg;
> > uint64_t status;
> > uint64_t size;
>
> Put it at the end of the other group i.e. move the blank line.
>
> There are now *three* entries in the PV struct referring to the VG.
> - vg_name
> - vgid
> - vg
>
> Why do we need 3?
> - Historically, only the name was used.
> - We added vgid to distinguish between different VGs with the same name plugged
> into a system.
> - The new 'vg' field as proposed is *independent* of those two existing ones, and
> is set and maintained when the PV belongs to a 'pvs' list in a parent VG struct.
> Please make that clear in a comment by the field.
>
Ok yes, I will add the comment/explanation.
I started to see if I could refactor such that I remove vgname and vgid
from struct physical_volume and just reference vg->name and vg->id, but
it may be more trouble than it is worth. Ideally all we need is 'vg',
but this assumes the VG is constructed at all times when the vgname and
vgid fields are needed. When we read labels though, and dip into the vg
metadata for the vgname, etc, we don't really construct the vg at this
point, so it might not be something that could be easily/safely
refactored. Then again, longer term we may want to sub-divide the vg
into a "vg header" which contains just what we read at label_read()
time, and then we could conceivably refactor this I think.
next prev parent reply other threads:[~2010-04-06 13:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-05 19:51 [PATCH 0/5] Add pv->vg link, v2 Dave Wysochanski
2010-04-05 19:51 ` [PATCH 1/5] Add pv to vg->pvs after check for maximum value of vg->extent_count Dave Wysochanski
2010-04-05 19:51 ` [PATCH 2/5] Refactor _read_pv() code that updates vg->extent_count and vg->free_count Dave Wysochanski
2010-04-05 19:51 ` [PATCH 3/5] Refactor format1 vg->pvs list add and vg->pv_count Dave Wysochanski
2010-04-05 19:51 ` [PATCH 4/5] Add add_pvl_to_vgs() - helper function to add a pv to a vg list Dave Wysochanski
2010-04-05 19:51 ` [PATCH 5/5] Add pv->vg to solidify link between a pv and a vg Dave Wysochanski
2010-04-06 13:27 ` Alasdair G Kergon
2010-04-06 13:48 ` Dave Wysochanski [this message]
2010-04-06 13:39 ` Alasdair G Kergon
2010-04-06 13:15 ` [PATCH 4/5] Add add_pvl_to_vgs() - helper function to add a pv to a vg list Alasdair G Kergon
2010-04-06 13:06 ` [PATCH 3/5] Refactor format1 vg->pvs list add and vg->pv_count Alasdair G Kergon
2010-04-06 13:03 ` [PATCH 2/5] Refactor _read_pv() code that updates vg->extent_count and vg->free_count Alasdair G Kergon
2010-04-06 12:59 ` [PATCH 1/5] Add pv to vg->pvs after check for maximum value of vg->extent_count Alasdair G Kergon
-- strict thread matches above, loose matches on Subject: below --
2010-04-06 23:53 [PATCH 0/5] Add pv->vg link, v3 Dave Wysochanski
2010-04-06 23:53 ` [PATCH 1/5] Remove unnecessary parameter from import_pool_pvs() Dave Wysochanski
2010-04-06 23:53 ` [PATCH 2/5] Move increment of vg->pv_count from import_pool_vg() to import_pool_pvs() Dave Wysochanski
2010-04-06 23:53 ` [PATCH 3/5] Add del_pvl_from_vgs() and move prototypes into metadata-exported.h Dave Wysochanski
2010-04-06 23:53 ` [PATCH 4/5] Call add_pvl_to_vgs() and del_pvl_from_vgs() from more places Dave Wysochanski
2010-04-06 23:53 ` [PATCH 5/5] Add pv->vg to solidify link between a pv and a vg Dave 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=1270561709.16846.6.camel@f10-node1 \
--to=dwysocha@redhat.com \
--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.