[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [lvm-devel] [PATCH 09/22] Replicator: add sorted vgs_list

Dne 26.4.2010 16:34, Alasdair G Kergon napsal(a):
> On Mon, Apr 12, 2010 at 05:21:37PM +0200, Zdenek Kabelac wrote:
>> Introduce struct vgs_list to store information about needed
>> volume group name, vgid, flags and the pointer to opened VG.
> Why does this need a new structure?

We don't have any similar one - I would be aware of.

Using new structure here seems to simplify modification of routines to be able
to process some loops multiple times  - i.e. code changes are minimal to
extend it for work with remote VGs.

> How does this interact with internal caches?

There is no interaction  - VGs are opened in alphabetical order via standard
lvm mechanism - there are no peeks into internal caches.

Technically we could find names in caches - but we should also keep locks for
all VGs during activation so noone changes them.

> How does this interact with 'struct volume_group' itself?  (The fields are
> already part of it so why is a new struct needed?)

We keep list of needed VGs outside in command - once we open 'master' VG -
list is moved (spliced) to internal VG list - then it's filled with
potentially missing 'other VGs' - later - if there was found problem in
processing caused by missing VG - list is taken out of VG - and in
alphabetical order opened again. And this loop iterates until either all
missing VGs are satisfied or some VG couldn't be opened -> failing resource.
This is a bit tricky - but we do not need to put things to global structure
like cmd_context in this case.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]