RFC Waiting for the missing device in mirror
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 6 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 6 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC 0/6] Waiting for the missing device in mirror
Dne 8.6.2015 v 09:48 Lidong Zhong napsal(a):
Quoted 7 lines
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.
Quoted 6 lines
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