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

[Dan Lambright]

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"


----- 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