[Gluster-devel] [RFC] FUSE bridge based on GlusterFS API

[Oleksandr Natalenko]

11.04.2016 11:14, Niels de Vos wrote:
> I would like to add a detection for a xglfs executable in the
> /sbin/mount.glusterfs script. This then makes it possible to replace 
> the
> original FUSE client with xglfs. If we do something similar in our
> regression tests, we can get an idea how stable and feature complete
> xglfs is.

I believe adding it to tests prior to adding to packaged 
/sbin/mount.glusterfs script should be the first step.

> I assume this is like the FIBMAP-ioctl().

So, obviously, we do not need it.

> We actually do have a flush FOP in the GlusterFS protocol and xlators.
> But is has not been added to libgfapi. The library calls flush from
> glfs_close(). I'm not sure we really need to add glfs_flush() to
> libgfapi, most (all?) applications would likely use glfs_fsync() 
> anyway?

I've added dummy handler for this fop to always return 0. It shouldn't 
be a big deal to replace it with actual implementation if libgfapi gains 
glfs_flush() support.

> There is both glfs_fsync() and glfs_fdatasync(). These match their
> fsync() and fdatasync() counterparts.

OK, so they are implemented correctly in xglfs now.

>> * .fsyncdir fop (again, wtf?);
> 
> This is like calling fsync() on a directory. It guarantees that changes
> in the directory (new/unlinked files) are persistent.

Cannot find similar function in GlusterFS API. Should it be implemented 
first, or we are fine to proceed with dummy handler returning 0?

>> * WHERE IS MY glfs_truncate()?
> 
> Almost there, Jeff sent a patch. We just need a bug to linke the patch
> against.

Saw that, many thanks to Jeff for accepting the challenge :).

> Would you be willing to move the GitHub repository under
> github.com/gluster ? It gives a little move visibility in our community
> that way.

See no issue with that. Ping me in IRC to arrange the movement.

Regards,
   post-factum