On Thu, Apr 07, 2016 at 10:32:18PM +0300, Oleksandr Natalenko wrote: > Hello. > > Pranith and Niels encouraged me to share here my toy project of simple FUSE > bridge that uses GlusterFS API [1]. Many thanks for announcing your project! > The rationale for this is that FUSE bridge currently present in GlusterFS code > does not use GlusterFS API, and that is considered to be wrong, and there are > some plans to replace it with modern solution. xglfs code could potentially go > under glusterfs tree if the developers decide it should happen. Also, it could > be rpm'ed and suggested to Fedora users. Jeff already explained some of the history, so I won't repeat that. What I'd like to see, is to reduce the amount of client-side implementations in hte main Gluster codebase. Removing the currect FUSE client, and have it replaced by your xglfs project can be a long term goal. It would probably be best to keep xglfs in its own repository, just like other clients that use libgfapi. > Now xglfs it is just a separate executable that relies on glusterfs-devel and > fuse-devel packages and does simple conversion between FUSE VFS calls and > GlusterFS API. Thanks to API completeness (well, glfs_truncate() is an > exception, AFAIK), this custom bridge is really thin and small. libgfapi is a gluster-client, just like the current glusterfs-fuse base. By building on top of libgfapi on one side, and libfuse on the other, the connection functions are expected to be relatively simple and small. Great to see that this actually is the case :-) > As a guide I used Big Brother File System code by Joseph J. Pfeiffer, Jr. [2] > that is freely available in the Internet (version 2014-06-12, but newer > version has been released recently). However, I've adopted it to current FUSE > libs reality just by inspecting /usr/include/fuse/fuse.h carefully and > defining FUSE_USE_VERSION=26 explicitly. > > What I would like for reviewers to pay an attention for: > > * error path handling correctness (mostly, negated errno value is returned, is > that correct?); > * fops semantic correctness; > * everything else you would like to comment on or suggest. > > The code itself has been verified by GCC, Clang (+analyzer), Intel C Compiler, > cppcheck and Valgrind. No idea what could go wrong there :). However, I'm not > responsible for data damage caused by this project, of course. 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. > Some things remain not so clear to me: > > * FUSE .bmap fop (wtf is that?); I assume this is like the FIBMAP-ioctl(). > * trickery with .fgetattr (do we need that trickery?); > * .flush fop (no GlusterFS equivalent?); 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? > * fsync/fdatasync difference for GlusterFS; There is both glfs_fsync() and glfs_fdatasync(). These match their fsync() and fdatasync() counterparts. > * .fsyncdir fop (again, wtf?); This is like calling fsync() on a directory. It guarantees that changes in the directory (new/unlinked files) are persistent. > * WHERE IS MY glfs_truncate()? Almost there, Jeff sent a patch. We just need a bug to linke the patch against. > Feel free to happily accept this project or ignore it silently. Nevertheless, > I would be happy to see your pull requests or comments, or even results of > some test you might want to perform on you critical production. Also, I know > that Soumya has already tried xglfs, and I would be glad if she shares some > experience on it. Would you be willing to move the GitHub repository under github.com/gluster ? It gives a little move visibility in our community that way. Cheers, Niels > > Best wishes, > post-factum > > [1] https://github.com/pfactum/xglfs > [2] http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/ >
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
