From: Peter Rajnoha <prajnoha@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH 04/17] Add format_instance support for pv_read.
Date: Wed, 26 Jan 2011 12:05:57 +0100 [thread overview]
Message-ID: <4D400015.5040908@redhat.com> (raw)
In-Reply-To: <87lj29ru07.fsf@twilight.int.mornfall.net.>
On 01/25/2011 02:30 PM +0100, Petr Rockai wrote:
> 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?
>
Well, we have plain PVs that are not part of any real VG yet, the orphan. BUT
we don't want to group them into an orphan VG (that would require collecting
all mdas from all orphan VGs). In this case, we have a pure PV fid defined
(this fid will include *only* the mdas on that PV).
Then we have plain PVs that are not part of any real VG yet, but are grouped
together into a virtual "orphan" VG. From fid's point of view, this is a VG
like any other, so the pv->fid references the VG-based pv->vg->fid.
Then we have PVs that are part of a real VG. These also have the pv->fid
referencing the pv->vg->fid.
This way, we can use the pv->fid transparently - we don't actually care
whether it is PV-based or VG-based fid, we only need to access the
mdas. Whether these mdas are store together in a pool with mdas from
other PVs (when in a VG) or they are just standalone mdas from that
one PV, we don't care. It makes writing the code easier. We don't
need to check that anymore...
> I think this is something that really needs to be documented. If nothing
..OK, I'll try to add some comments.
> 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
Actually, ORPHAN_VG_FID, VG_FID and PV_FID. But since ORPHAN_VG_FID == VG_FID
from fid's point of view, we have the separation PV_FID and VG_FID only
(which is exactly what the format_instance->pv_only flag is about)
> question, why we don't always use VG_FID even for orphans, given how we
E.g. creating a new PV, modifying just one PV etc. - there's no need to group
and store all the other mdas that are in that "virtual" orphan VG.
If we want to group that for some complex situations, OK. But it's useless
for simple modification done only on one PVs (iow, creating orphan VG fid
means collecting all mdas from all PVs not in a VG yet. And that could
be uselessly time-consuming for simple PV-only operations since we would
throw all that information away anyway).
> have an orphans VG? Would simply using the orphans VG FID be more
> consistent overall?
>
Please, let's not group into orphan VG where it's not really needed...
>> + 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.
>
It's because this _pv_read could be part of a vg_read (e.g. _vg_read_orphans).
So creating a standalone PV fid that would be destroyed immediately and
replaced by orphan VG fid would be useless, so it's better to pass the existing
fid in. So if it's defined already, we just merge PVs mdas into the fid and if
not, we create the new PV-based 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, ...)
>
The fid_add_mdas is part of the create_instance fn, so you would call that
code twice... (but this is related to the next patch also and I've seen the
comment briefly, so I'll reply there :) )
> ?
>
> 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...)
>
...
Peter
next prev parent reply other threads:[~2011-01-26 11:05 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
2011-01-26 11:05 ` Peter Rajnoha [this message]
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=4D400015.5040908@redhat.com \
--to=prajnoha@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.