On Wed, 11 Jul 2012 16:24:24 +0530, Amar Tumballi <atumball@xxxxxxxxxx> 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.
