Hi Mohan,
For the persistent gfid related issue discussed, could we look into mapping the lv_uuid and lg_uuid to act as their gfid's for glusterfs?
Assuming this to be unique across the cluster, we could guarantee persistence of these attributes, rather than generating them on the fly.
If the above scenario can be utilized, there are further issues to be looked into.
1. Can these uuid's be set through any interface?
2. Can just a uuid be sufficient for us to map it to a path? (to support nameless lookup's)
With regards,
Shishir
----- Original Message -----
From: "M. Mohan Kumar" <mohan@xxxxxxxxxx>
To: gluster-devel@xxxxxxxxxx
Sent: Wednesday, July 4, 2012 9:57:24 PM
Subject: [RFC] Block Device Xlator Design
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.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel
