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
