Refactoring pvmove with generic APIs
Get series with b4
b4 am [email protected]Versions newest first
- v1 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 [PATCH pvmove 0/6] Refactoring pvmove with generic APIs
Hi Heinz,
Thanks for the comment.
Quoted 4 lines · Heinz Mauelshagen
it would be better to make this more generic.
Ie.
convert_segments(struct lvm_conversion_handler *handler, ...)rather than having a per target conversion function.
Yes, generic interface is nice.
But as for conversion, I think starting from per-target conversion functions is better.
We may have a generic library interface like this:
int lv_convert(struct logical_volume *lv,
struct segment_type *segtype,
struct conversion_param *conv)
The conversion parameters are very specific to segment types. So callers have to set up the conversion_param based on the segtype.
Parameter are perhaps passed as an array of name-value pairs. I.e.
struct conversion_param {
int n_params;
struct {
const char *name;
const char *value;
} *params;}
conv = { 4,
{ { "mirrors", "3" }, { "region_size", "64" },
{ "log_count", "0" }, { "type", "segment-by-segment" } }
}And the segment type handlers interpret it.
I think it's good for external applications using liblvm2 but too much for LVM2 internal use.
What do you think?
Anyway, IMO, it's easy to add a generic wrapper once we make up underlying conversion functions for each segment types. So I think we should focus first on building up working conversion functions.
This pvmove patchset provides segment-by-segment conversion for mirror.
Next step would be whole-lv conversion for mirror. Then we can add a single wrapper for to-mirror conversion.
Thanks,
Signature · 1 line
Jun'ichi Nomura, NEC Corporation of America