[Gluster-devel] libgfapi zero copy write - application in samba, nfs-ganesha

Shyam srangana at redhat.com
Wed Sep 28 14:07:11 UTC 2016


On 09/27/2016 04:02 AM, Poornima Gurusiddaiah wrote:
> W.r.t Samba consuming this, it requires a great deal of code change in Samba.
> Currently samba has no concept of getting buf from the underlying file system,
> the filesystem comes into picture only at the last layer(gluster plugin),
> where system calls are replaced by libgfapi calls. Hence, this is not readily
> consumable by Samba, and i think same will be the case with NFS_Ganesha, will
> let the Ganesha folksc comment on the same.

This is exactly my reservation about the nature of change [2] that is 
done in this patch. We expect all consumers to use *our* buffer 
management system, which may not be possible all the time.

 From the majority of consumers that I know of, other than what Sachin 
stated as an advantage for CommVault, none of the others can use the 
gluster buffers at the moment (Ganesha, SAMBA, qemu. (I would like to 
understand how CommVault can use gluster buffers in this situation 
without copying out data to the same, just for clarity).

This is the reason I posted the comments at [1], stating we should copy 
out the buffer, when Gluster needs it preserved, but use application 
provided buffers as long as we can.

I do see the advantages of zero-copy, but not when gluster api is 
managing the buffers, it just makes it more tedious for applications to 
use this scheme, IMHO.

Could we think and negate (if possible) thoughts around using the 
application passed buffers as is? One caveat here seems to be when using 
RDMA (we need the memory registered if I am not wrong), as that would 
involve a copy to RDMA buffers when using application passed buffers. 
What are the other pitfalls?

[1] http://www.gluster.org/pipermail/gluster-devel/2016-August/050622.html

[2] http://review.gluster.org/#/c/14784/

>
>
> Regards,
> Poornima


More information about the Gluster-devel mailing list