[Gluster-devel] [RFC] Block Device Xlator Design

[M. Mohan Kumar]

On Wed, 11 Jul 2012 16:24:24 +0530, Amar Tumballi <atumball at redhat.com> wrote:
> 
> 
> >
> > I posted GlusterFS server xlator patches to enable exporting Block
> > Devices (currently only Logical Volumes) as regular files at the
> > client side couple of weeks ago. Here is the link for the patches:
> >         http://review.gluster.com/3551
> >
> > I would to like to discuss about the design of this xlator.
> >
> > Current code uses lvm2-devel library to find out list of logical volumes
> > for the given volume group (in BD xlator each volume file exports on
> > volume group, in future we may extend this to export multiple volume
> > groups if needed). init routine of BD xlator constructs internal data
> > structure holding list of all logical volumes in the VG.
> >
> 
> Went through the patchset, and it looks fine. One of the major thing to 
> take care is, the build should not fail or it should not assume that 
> lvm2-devel library is always present. Hence it should have corresponding 
> checks in configure.ac to handle the situation. (ref: you can look into 
> how libibverbs-devel dependency is handled)
> 
Amar,
This one is fixed in my current level of patchset. It will disable BD
xlator if system does not have lvm2-devel library. I also provided an option
to enable bd xlator explicitly during configure time. This will also
take care of reporting proper error if lvm2-devel is not there.
 
> > When open request comes corresponding open interface in BD xlator 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?
> 
> This should be fine. One concern here is how do we keep track of gfid to 
> path mappings. With having proper resolution there, we can guarantee the 
> behavior.
> 
I cross checked with lvm2-devel folks, they say this is the right
approach. As Shishir mentioned its possible to use VG/LV uuid as gfid.


> > But there are other issues in the BD xlator code as of now. lvm2 api
> > does not support resizing a LV, creating snapshot of LV. But there are
> > tools available to do the same. So BD xlator code forks and executes the
> > required binary to achieve the functionality. i.e when truncate is
> > called on a BD xlator volume, it will result in running lvresize binary
> > with required parameters. I checked with lvm2-devel mailing list about
> > their plan to support lv resizing and creating snapshots & waiting for
> > the responses.
> >
> > Is it okay to rely on external binaries to create a snapshot of a LV and
> > resize it?
> >
> 
> It is ok to call external binaries (security issues are present, but is 
> a different topic of discussion). Two things to take care here:
> 
> 1. as Avati rightly mentioned, utilize the runner 
> ('libglusterfs/src/run.h') interface.
> 
Thanks, my new gluster CLI patch uses this interface.

> 2. If you are expecting/waiting on return value of these binaries, then 
> we have to make sure we have a mechanism to handle hang situation.
> 
Yeah, I need to look in this aspect.