Hello,
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.
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?
Also if there is a request to create a file (in turn it has to create a
LV at the server side), lvm2 api is used to create a logical volume in
the given VG but with a pre-determined size ie one logical extent size
because create interface does not take size as one of the parameters but
size is one of the parameters to create a logical volume.
In a typical VM disk image scenario qemu-img first creates a file and
then uses truncate command to set the required file size. So this should
not be an issue with this kind of usage.
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?
Also when a LV is created out-of-band for example, using gluster cli to
create a LV (I am working on the gluster cli patches to create LV and
copy/snapshot LVs), BD xlator will not be aware of these changes and I
am looking if 'notify' feature of xlator can be used to notify the BD
xlator to create a LV, snapshot instead of doing it from gluster
management xlators. I have sent a mail to gluster-devel asking some more
information about this.
Regards,
M. Mohan Kumar.
