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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
