[RFC 0/6] Waiting for the missing device in mirror

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 8.6.2015 v 09:48 Lidong Zhong napsal(a):
> Hi List,
>
> The implementation here is trying to add another policy for the
> missing leg/log device in mirror. We want to wait the device for some
> time in case of a temporary device failure, especially a network disconnection
> for clvmd, to avoid a full disk recovery.
>
> This version is kind of a draft. There are many immature places to improve. So comments
> and suggestions are welcomed.
>
> The responding kernel part is here:
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/
> commit/?h=for-next&id=ed63287dd670f8e9d2412a913de7fdc50a689831

Hi

I think you should please start first with the very precise description what 
you are trying to achieve/fix - then we should discuss how to reach desired goal.

With very light overview of patches there are number of problem which can't 
fit lvm2 design.

#1 - Never store any device major:minor in lvm2 metadata - everything is 
strictly PV UUID oriented (there are number of daemons these days)

#2 - Activation layer & Command layer are 2 separate entities - so your 
command may run on different node then the actual activation happens (unless 
you do a local activation) -  the layer separator is ATM 'lock' - the code 
before lock and  after lock do not share any data - and the 'activation' layer 
knows only what is in written metadata on disk (just for optimization purposes 
there is some internal mechanism of caching and reusing of some existing data).

#3 - There is no 'hidden' data exchange channel via /tmp for activation - 
everything goes strictly via written and committed metadata, and for every 
such metadata state there needs to be some clear recovery path (e.g. what 
happens after 'power-off' with each committed lvm2 metadata state)

I do not yet quite understand what are you trying to achieve - but I've not 
noticed any patch for 'dmeventd' which is the actual tool that fixes broken 
mirrors - so could that tool by anyhow used for detection of some temporary 
network failures ?

Regards

Zdenek