From: Petr Rockai <prockai@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH 04/17] Add format_instance support for pv_read.
Date: Tue, 25 Jan 2011 14:30:00 +0100 [thread overview]
Message-ID: <87lj29ru07.fsf@twilight.int.mornfall.net.> (raw)
In-Reply-To: <1295867048-21558-5-git-send-email-prajnoha@redhat.com> (Peter Rajnoha's message of "Mon, 24 Jan 2011 12:03:55 +0100")
Peter Rajnoha <prajnoha@redhat.com> writes:
> We don't need to store metadata areas in a separate "mdas" parameter
> since it is in the pv->fid now. If the fid is not defined yet and is
> NULL, pv_read code will create a new one (if there's no VG fid yet
> where the metadata areas read off of a PV should be attached to).
This is somewhat hairy... With this patch, it's starting to seem that PV
will sometimes point to a VG FID and other times to PV FID. Is there a
good reason for that? Is the PV FID only used with orphan PVs?
I think this is something that really needs to be documented. If nothing
else, the format_instance type value (as suggested in an earlier
comment) should read ORPHAN_PV_FID and VG_FID. It also does raise the
question, why we don't always use VG_FID even for orphans, given how we
have an orphans VG? Would simply using the orphans VG FID be more
consistent overall?
Please also see below.
> ---
> lib/metadata/metadata.c | 26 +++++++++++++++++++++-----
> 1 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/lib/metadata/metadata.c b/lib/metadata/metadata.c
> index ed2084d..f6ea0e5 100644
> --- a/lib/metadata/metadata.c
> +++ b/lib/metadata/metadata.c
> @@ -37,6 +37,7 @@
> static struct physical_volume *_pv_read(struct cmd_context *cmd,
> struct dm_pool *pvmem,
> const char *pv_name,
> + struct format_instance *fid,
> struct dm_list *mdas,
> uint64_t *label_sector,
> int warnings, int scan_label_only);
> @@ -166,6 +167,7 @@ void add_pvl_to_vgs(struct volume_group *vg, struct pv_list *pvl)
> dm_list_add(&vg->pvs, &pvl->list);
> vg->pv_count++;
> pvl->pv->vg = vg;
> + pvl->pv->fid = vg->fid;
> }
>
> void del_pvl_from_vgs(struct volume_group *vg, struct pv_list *pvl)
> @@ -1813,7 +1815,7 @@ static struct physical_volume *_find_pv_by_name(struct cmd_context *cmd,
> struct physical_volume *pv;
>
> dm_list_init(&mdas);
> - if (!(pv = _pv_read(cmd, cmd->mem, pv_name, &mdas, NULL, 1, 0))) {
> + if (!(pv = _pv_read(cmd, cmd->mem, pv_name, NULL, &mdas, NULL, 1, 0))) {
> log_error("Physical volume %s not found", pv_name);
> return NULL;
> }
> @@ -1822,7 +1824,7 @@ static struct physical_volume *_find_pv_by_name(struct cmd_context *cmd,
> /* If a PV has no MDAs - need to search all VGs for it */
> if (!scan_vgs_for_pvs(cmd, 1))
> return_NULL;
> - if (!(pv = _pv_read(cmd, cmd->mem, pv_name, NULL, NULL, 1, 0))) {
> + if (!(pv = _pv_read(cmd, cmd->mem, pv_name, NULL, NULL, NULL, 1, 0))) {
> log_error("Physical volume %s not found", pv_name);
> return NULL;
> }
> @@ -2644,7 +2646,8 @@ static struct volume_group *_vg_read_orphans(struct cmd_context *cmd,
> }
>
> dm_list_iterate_items(info, &vginfo->infos) {
> - if (!(pv = _pv_read(cmd, mem, dev_name(info->dev), NULL, NULL, warnings, 0))) {
> + if (!(pv = _pv_read(cmd, mem, dev_name(info->dev), vg->fid,
> + NULL, NULL, warnings, 0))) {
> continue;
> }
> if (!(pvl = dm_pool_zalloc(mem, sizeof(*pvl)))) {
> @@ -3357,13 +3360,14 @@ struct physical_volume *pv_read(struct cmd_context *cmd, const char *pv_name,
> struct dm_list *mdas, uint64_t *label_sector,
> int warnings, int scan_label_only)
> {
> - return _pv_read(cmd, cmd->mem, pv_name, mdas, label_sector, warnings, scan_label_only);
> + return _pv_read(cmd, cmd->mem, pv_name, NULL, mdas, label_sector, warnings, scan_label_only);
> }
>
> /* FIXME Use label functions instead of PV functions */
> static struct physical_volume *_pv_read(struct cmd_context *cmd,
> struct dm_pool *pvmem,
> const char *pv_name,
> + struct format_instance *fid,
> struct dm_list *mdas,
> uint64_t *label_sector,
> int warnings, int scan_label_only)
> @@ -3407,6 +3411,18 @@ static struct physical_volume *_pv_read(struct cmd_context *cmd,
> if (!alloc_pv_segment_whole_pv(pvmem, pv))
> goto_bad;
>
> + if (fid)
> + fid_add_mdas(fid, &info->mdas, (const char *) &pv->id, ID_LEN);
> + else {
> + if (!(pv->fid = pv->fmt->ops->create_instance(pv->fmt,
> + (const char *) &pv->id,
> + NULL, NULL, NULL))) {
> + log_error("_pv_read: Couldn't create format instance "
> + "for PV %s", pv_name);
> + goto bad;
> + }
> + }
> +
The code above is certainly confusing. A comment is needed, explaining
what is going on. Please explain that non-NULL "fid" means that this PV
belongs to a VG, and the fid variable points to that VG's fid.
Also, why mdas are added to the VG fid, but the (orphan) PV fid is left
empty? Should the code read
if (!fid) {
if (!(fid = pv->fid = ...
}
fid_add_mdas(fid, ...)
?
If, as I suspect, it's because create_instance adds the MDA's itself,
please add a comment to that effect. (Also, is it necessary that
create_instance does this? I am not sure it is entirely intuitive...)
> return pv;
> bad:
> _free_pv(pvmem, pv);
> @@ -4213,5 +4229,5 @@ struct physical_volume *pv_by_path(struct cmd_context *cmd, const char *pv_name)
> struct dm_list mdas;
>
> dm_list_init(&mdas);
> - return _pv_read(cmd, cmd->mem, pv_name, &mdas, NULL, 1, 0);
> + return _pv_read(cmd, cmd->mem, pv_name, NULL, &mdas, NULL, 1, 0);
> }
Yours,
Petr
next prev parent reply other threads:[~2011-01-25 13:30 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 11:03 [PATCH 00/17] Add interface to support adding and removing metadata areas on demand (v2) Peter Rajnoha
2011-01-24 11:03 ` [PATCH 01/17] Add pvid parameter to create_instance function Peter Rajnoha
2011-01-25 12:54 ` Petr Rockai
2011-01-24 11:03 ` [PATCH 02/17] Add supporting functions for metadata areas stored in format instance Peter Rajnoha
2011-01-25 13:16 ` Petr Rockai
2011-01-26 10:38 ` Peter Rajnoha
2011-01-26 13:59 ` Petr Rockai
2011-01-26 14:06 ` Petr Rockai
2011-01-24 11:03 ` [PATCH 03/17] Add struct format_instance *fid field to struct physical_volume Peter Rajnoha
2011-01-25 13:03 ` Petr Rockai
2011-01-24 11:03 ` [PATCH 04/17] Add format_instance support for pv_read Peter Rajnoha
2011-01-25 13:30 ` Petr Rockai [this message]
2011-01-26 11:05 ` Peter Rajnoha
2011-01-26 11:12 ` Peter Rajnoha
2011-01-24 11:03 ` [PATCH 05/17] Add attach_existing_mdas parameter to create_instance fn Peter Rajnoha
2011-01-25 14:43 ` Petr Rockai
2011-01-26 13:24 ` Peter Rajnoha
2011-01-24 11:03 ` [PATCH 06/17] Remove useless mdas parameter from PV read functions Peter Rajnoha
2011-01-25 14:44 ` Petr Rockai
2011-01-24 11:03 ` [PATCH 07/17] Add pv_add_metadata_area fn to support adding metadata areas on demand Peter Rajnoha
2011-01-25 14:48 ` Petr Rockai
2011-01-24 11:03 ` [PATCH 08/17] Add pv_remove_metadata_area fn to support removing " Peter Rajnoha
2011-01-28 15:31 ` Petr Rockai
2011-01-24 11:04 ` [PATCH 09/17] Add pv_initialise fn to format_handler interface Peter Rajnoha
2011-01-28 16:31 ` Petr Rockai
2011-01-24 11:04 ` [PATCH 10/17] Add pe_start_locked parameter to pv_create fn Peter Rajnoha
2011-01-28 16:39 ` Petr Rockai
2011-01-24 11:04 ` [PATCH 11/17] Refactor pv_setup to not include the PV initialisation code Peter Rajnoha
2011-01-24 11:04 ` [PATCH 12/17] Remove unused _mda_setup code Peter Rajnoha
2011-01-24 11:04 ` [PATCH 13/17] Cleanup pv_write code to use recent changes in metadata handling interface Peter Rajnoha
2011-01-24 11:04 ` [PATCH 14/17] Use new metadata handling interface to provide better support for PV resize Peter Rajnoha
2011-01-24 11:04 ` [PATCH 15/17] Change vg_convert code to actually work with recent changes in metadata handling interface Peter Rajnoha
2011-01-24 11:04 ` [PATCH 16/17] Fix pvchange -u to " Peter Rajnoha
2011-01-24 16:04 ` Peter Rajnoha
2011-01-24 11:04 ` [PATCH 17/17] Fix pvchange --metadataignore " Peter Rajnoha
2011-01-24 11:12 ` [PATCH 00/17] Add interface to support adding and removing metadata areas on demand (v2) Peter Rajnoha
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=87lj29ru07.fsf@twilight.int.mornfall.net. \
--to=prockai@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.