lvm2app: Adding lv creation support
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 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/PATCH 0/2] lvm2app: Adding lv creation support
Quoted 19 lines · Tony Asleson
Quoted 11 lines · M. Mohan Kumar
From: "M. Mohan Kumar" <[email protected]>
Hello,
We added Block Device(BD) backend capability to GlusterFS last year. BD backend takes volume group as the input for GlusterFS volume and exports all logical volumes under it as regular files to the GlusterFS client. Now we are planning to export thin LVs as also regular files through GlusterFS. In order to support thin LVs, we need thin lv creation support in the lvm-devel.
Quoted 6 lines
I am posting RFC patches for adding various lv target creation support and thin(pool) lv creation support in lvm library.
First approach (Add thin and thin pool lv creation) adds two interfaces
lvm_lv_thinpoolandlvm_lv_thin(similar tolvm_vg_create_lv_linear()) to create thin-pool LV and thin LV respectively.
Quoted 6 lines
Thanks for the patches!
This patch looks pretty straight forward. Ideally we would not have the function do the write and commit to match the other functions. Did you happen to take a peek to what that would involve?
This function is based on existing function lvm_vg_create_lv_linear. This existing function does not call lvm_vg_write. or am I missing something here?
Quoted 13 lines
Quoted 13 lines
Second approach (Add LV creation support) adds interface
lvm_vg_create_lv()that can be used to create LV of any target type (stripe, mirror, raid, thin etc). As part of this interface a new structurelv_params_tis addded which is similar tolvcreate_paramsexposing all parameters (such as chunk size, stripe size etc) to the end user. Advantage with this approach is that it gives the user to control properties of new LVs such as if the minor number of new lv should be persistent, allocation policy, permission mode, stripe size etc. But problem with this approach is that lots of code (parameter parsing, setting default value for LV properties etc) from tools is duplicated and it needs to be made as a library so that both tools and lvm-devel can consume them.
Quoted 8 lines
Quoted 2 lines
In the long run, lvm-devel may need to provide finer control to the user when creating LVs. In that case second approach is more suitable.
I agree with everything you state here and I also agree with your comments about moving the code into a common spot instead of copying it.
I see that you do have some slight differences in the copied functions,
but those are required.
I need to modify some of the validation as it was not needed in case of parameter passed by user.
Quoted 9 lines
Exposing parameter passing with the use of structures is typically discouraged in a shared C API. The struct padding can be different from client application and library compile based on compiler settings. If we go this route we should at the very least do a pragma pack to mitigate this. In addition once you do this the structure forever cannot change. We could address these issues by creating an opaque data type and then adding some functions to set/get the values from the opaque handle. Kind of tedious, but it is a common approach.
Quoted 3 lines
Not sure what else we could do to offset the vast number of arguments that are available.
I agree, can we try something like this:lv_set_param(mirror, value_for_mirror, opaque structure); lv_set_param(region_size, value_for_region_size, opaque structure);