For a project I am working on, I need to identify (or build) a FUSE
meta-filesystem driver that will manage cloud storage from disparate
cloud storage providers as an overlay on top of vendor-specific FUSE
drivers. I am currently looking at GlusterFS - perhaps using multiple
glusterfsd daemons on a server, exporting the cloud file systems as
volumes, then using a modified glusterfs client process to create a
composite, unified volume from the multiple cloud file systems.
Now, why would I use vendor-specific FUSE drivers rather than just
directly on the vendor API, and why do I need two FUSE abstraction
layers? I understand that two FUSE abstraction layers would be much more
inefficient than coding one layer to use the APIs of the vendors, but
cloud drives are not speed demons anyway - and to add an additional API
would not require a lot of interface glue, I think. In the alternative,
I would have to consider the idiosyncrasies of every API, and some APIs
are proprietary and/or unpublished. Since the vendor's drivers would
have to conform to the published FUSE API, whatever their individual
idiosyncrasies, the interface should be simpler.
Any comments or suggestions regarding this approach?
Peter
