lvm2-api usage in GlusterFS

lvm2-api usage in GlusterFS

[M.Mohan Kumar]

Hello,

I am working on adding a GlusterFS feature to enable exporting Logical
volumes as regular files to GlusterFS client. Here is the link for the
patches:
       http://review.gluster.com/3551

GlusterFS patches use lvm2-devel library to find out list of logical
volumes for the given volume group and creating LVs etc.

When open request comes in the gluster mount path, server side code
opens the intended LV by using this logic: /dev/<vg-name>/<lv-name>.
This path is actually a symbolic link to /dev/dm-<x>. Is my assumption
about having this /dev/<vg-name>/<lv-name> is it right? Will it
always work?

Also other issues with the patch is resizing and creating a snapshot
of LV. There is no API to resize a LV and as of now I am using the
lvresize binary to resize the LV by forking and executing it. Also when
creating a snapshot of LV, I am forking and executing lvcreate binary
with appropriate parameters.

Is there any plan to add support to resize a LV and create snapshot of
LV?

Regards,
M. Mohan Kumar.

lvm2-api usage in GlusterFS

[Alasdair G Kergon]

On Wed, Jul 04, 2012 at 11:02:11PM +0530, M.Mohan Kumar wrote:
> When open request comes in the gluster mount path, server side code
> opens the intended LV by using this logic: /dev/<vg-name>/<lv-name>.
> This path is actually a symbolic link to /dev/dm-<x>. Is my assumption
> about having this /dev/<vg-name>/<lv-name> is it right? Will it
> always work?
 
That is the right link to use as it depends only on the VG name and the LV
name.

The /dev/mapper and /dev/dm-N entries might change.

Alasdair

lvm2-api usage in GlusterFS

[M. Mohan Kumar]

On Wed, 4 Jul 2012 18:41:48 +0100, Alasdair G Kergon <agk@redhat.com> wrote:
> On Wed, Jul 04, 2012 at 11:02:11PM +0530, M.Mohan Kumar wrote:
> > When open request comes in the gluster mount path, server side code
> > opens the intended LV by using this logic: /dev/<vg-name>/<lv-name>.
> > This path is actually a symbolic link to /dev/dm-<x>. Is my assumption
> > about having this /dev/<vg-name>/<lv-name> is it right? Will it
> > always work?
> 
> That is the right link to use as it depends only on the VG name and the LV
> name.
> 
> The /dev/mapper and /dev/dm-N entries might change.

Thanks Alasdair.

Do you have any idea about plan to add api support to resize lv and
create snapshot LVs?

lvm2-api usage in GlusterFS

[Alasdair G Kergon]

On Wed, Jul 04, 2012 at 11:02:11PM +0530, M.Mohan Kumar wrote:
> Also other issues with the patch is resizing and creating a snapshot
> of LV. There is no API to resize a LV and as of now I am using the

int lvm_lv_resize(const lv_t lv, uint64_t new_size);

"NOTE: This function is currently not implemented."

> Is there any plan to add support to resize a LV and create snapshot of
> LV?
 
Well we're about to start a review of the state of this interface, so if
you have any more suggestions, please send them too.

Alasdair

lvm2-api usage in GlusterFS

[M. Mohan Kumar]

On Wed, 4 Jul 2012 21:57:49 +0100, Alasdair G Kergon <agk@redhat.com> wrote:
> On Wed, Jul 04, 2012 at 11:02:11PM +0530, M.Mohan Kumar wrote:
> > Also other issues with the patch is resizing and creating a snapshot
> > of LV. There is no API to resize a LV and as of now I am using the
> 
> int lvm_lv_resize(const lv_t lv, uint64_t new_size);
> 
> "NOTE: This function is currently not implemented."
> 
> > Is there any plan to add support to resize a LV and create snapshot of
> > LV?
> 
> Well we're about to start a review of the state of this interface, so if
> you have any more suggestions, please send them too.
> 

It will be great if lvm library supports following interfaces

1) lvresize

2) lv snapshot creation

3) lvrename

4) Possible to set some properties per LV, something like gluster may
set a attribute (for ex: attribute:owner, value:gluster) in each LV
created by it so that gluster (or who ever created an LV) can filter
LVs that are not created by gluster (I am just listing one of the use cases)

5) Ability to do the full copy of LVs, for example: lv_copy (lv_t dest,
lv_t source). If its possible to implement in the kernel itself, we can
avoid user space copying incurred in read/write.

6) Ability to provide list of logical blocks and the physical disk for a
given LV so that these blocks can be given to libStorageManagement tool
to offload storage operations (such as full cloning a LV)
 
7) Ability to create other targets for example lv library giving
interface to create a dm-thinpool, dm-thintarget etc.


Regards,
M. Mohan Kumar

lvm2-api usage in GlusterFS

[M. Mohan Kumar]

On Fri, 24 Aug 2012 12:52:24 +0530, "M. Mohan Kumar" <mohan@in.ibm.com> wrote:
> On Wed, 4 Jul 2012 21:57:49 +0100, Alasdair G Kergon <agk@redhat.com> wrote:
> > On Wed, Jul 04, 2012 at 11:02:11PM +0530, M.Mohan Kumar wrote:
> > > Also other issues with the patch is resizing and creating a snapshot
> > > of LV. There is no API to resize a LV and as of now I am using the
> > 
> > int lvm_lv_resize(const lv_t lv, uint64_t new_size);
> > 
> > "NOTE: This function is currently not implemented."
> > 
> > > Is there any plan to add support to resize a LV and create snapshot of
> > > LV?
> > 
> > Well we're about to start a review of the state of this interface, so if
> > you have any more suggestions, please send them too.
> > 
> 
> It will be great if lvm library supports following interfaces
> 
> 1) lvresize
> 
> 2) lv snapshot creation
> 
> 3) lvrename
> 
> 4) Possible to set some properties per LV, something like gluster may
> set a attribute (for ex: attribute:owner, value:gluster) in each LV
> created by it so that gluster (or who ever created an LV) can filter
> LVs that are not created by gluster (I am just listing one of the use cases)
> 
> 5) Ability to do the full copy of LVs, for example: lv_copy (lv_t dest,
> lv_t source). If its possible to implement in the kernel itself, we can
> avoid user space copying incurred in read/write.
> 
> 6) Ability to provide list of logical blocks and the physical disk for a
> given LV so that these blocks can be given to libStorageManagement tool
> to offload storage operations (such as full cloning a LV)
> 
> 7) Ability to create other targets for example lv library giving
> interface to create a dm-thinpool, dm-thintarget etc.
> 
Hi Alasdair,

Whats your opinion on this request?