[Gluster-users] glusterfs via libgfapi as local block device?

[Lalatendu Mohanty]

On 03/29/2014 06:53 PM, Dan Lambright wrote:
> Dave,
>
> The Linux target driver has a back-end module to gluster using libgfapi. You can use iSCSI in this way to connect to gluster.
>
> http://stgt.sourceforge.net/
>
> Below I paste the README.glfs file.
>
> Feel free to email me if you have any questions about it.
>
> ----
>
> The 'glfs' backing-store driver provides block  access to a file within the
> gluster distributed  file system  (www.gluster.org). The file  represents a
> LUN visible to the  initiator (the file may be a  regular file in gluster's
> underlying XFS filesystem, or a gluster "block device"). This configuration
> gives gluster support for any access method supported by the target driver,
> such as iSCSI.
>
> The backing-store  driver uses  the interfaces  to gluster  in libgfapi.so.
> This file is part of the glusterfs-api package which can be downloaded from
> www.gluster.org.
>
> To  build  the glfs  backing  store  driver,  set the  GLFS_BS  environment
> variable (export GLFS_BD=1) before running Make.
>
> When a LUN on a target is created with backing store of type glfs (--bstype
> glfs), a  handle to gluster  is created. The  handle is destroyed  when the
> target is  closed. The handle represents  a particular volume on  a gluster
> server and a particular file representing the LUN.
>
> To  set  the gluster  volume  and  file,  --backing-store takes  the  form:
> volume at hostname:filename
>
> For example, if the volume name was  vol1 , and the host gprfs010, and file
> name was "disk1", you would set --backing-store to:
>
> --backing-store="vol1 at gprfs010:disk1"
>
> For each CDB, the driver issues an appropriate gluster api call against the
> handle.  For  example,  WRITE_16 becomes  glfs_pwrite(),  SYNCHRONIZE_CACHE
> becomes glfs_fdatasync() and UNMAP becomes glfs_discard().
>
> Each call is synchronous, meaning the  thread will wait for a response from
> gluster before  returning to  the caller.  The libgfapi  interfaces support
> asynchronous  calls, and  an asynchronous  version of  the driver  has been
> tested. For  more information  on the  asynchronous version  please contact
> dlambrig at redhat.com.
>
> If the  backing store driver  was not used,  the linux target  driver could
> still write data  to gluster by loopback mounting the  gluster file system.
> The backing-store would be a file within the file system. Gluster uses FUSE
> to forward  I/O from  the kernel  to it's user  space daemon.  The overhead
> incured by FUSE and the kernel is removed when the backing store driver and
> libgfapi package is used.
>
> The libgfapi interfaces  supports logs. You can use the  --bsopts option to
> set the logfile and loglevel.
>
> --bsops="logfile=glfs.log;loglevel=3"
>

Here is some documentation on gluster wiki [1]

[1] http://www.gluster.org/community/documentation/index.php/GlusterFS_iSCSI


> ----- Original Message -----
> From: "Dave Christianson" <davidchristianson3 at gmail.com>
> To: gluster-users at gluster.org
> Sent: Saturday, March 29, 2014 9:11:25 AM
> Subject: [Gluster-users] glusterfs via libgfapi as local block device?
>
> I see many posts regarding using libgfapi for qemu guest voluimes, but how about as a mounted volume at the OS level? Is there a way to mount a glusterfs share as a local block device in Linux, bypassing the FUSE? Instead of doing a mount -t glusterfs server:/volume, which appears as type fuse.glusterfs, can libgfapi be used to allow direct access and eliminate the fuse overhead? Do i need to set this up as iSCSI target in order for this to work?
>
> Thanks,
> Dave
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users