[lvm-devel] [PATCH 4/7] Introduce vg_add_lc and vg_remove_lv functions.
Milan Broz
mbroz at redhat.com
Tue May 12 13:37:23 UTC 2009
Petr Rockai wrote:
> Btw., would vg_link_lv and vg_unlink_lv describe better what these two
> functions do? It seems a little easy to confuse _add_lv and vg_add_lv, while
> the two do quite a different thing.
yes, renamed
>> @@ -331,7 +330,7 @@ int import_lv(struct dm_pool *mem, struct logical_volume *lv, struct lv_disk *lv
>> lv->alloc = ALLOC_NORMAL;
>>
>> if (!lvd->lv_read_ahead)
>> - lv->read_ahead = lv->vg->cmd->default_settings.read_ahead;
>> + lv->read_ahead = cmd->default_settings.read_ahead;
>> else
>> lv->read_ahead = lvd->lv_read_ahead;
>>
> I'm not sure why is this change needed? (Adding cmd_context parameter to
> import_lv.)
just code shuffle, because lv->vg is initialized later in vg_add_lv and we
need cmd for default settings.
(probably explains some code shuffle later too)
> Does not change what the code does, just shuffles the lines somewhat. It does
> change semantics of import_lv, but that function is never used outside _add_lv
> anyway (would it make sense to make it static _import_lv, in a separate
> patch?).
ok, I'll move it to separate patch
>> + //FIXME: cow still in VG, fix count, remove this later
>> + if (lv->status & SNAPSHOT)
>> + lv->vg->lv_count++;
> ^^ This is indeed ugly (see also my previous mail: it might be worth getting
> rid of lv_count altogether) ... although this patch is a definite improvement,
> it is still suboptimal in this respect.
later patch removes that, I keep it here just that every separate patch can pass
full testing.
Milan
More information about the lvm-devel
mailing list