On 11/13/2010 09:03 PM, Pete Zaitcev wrote: > On Fri, 12 Nov 2010 13:14:45 -0500 > Jeff Darcy<jdarcy@xxxxxxxxxx> wrote: > >> As mentioned in the IRC meeting yesterday, I've put together a CloudFS >> feature proposal at https://fedoraproject.org/wiki/Features/CloudFS. >> Feedback would be most welcome. > > I have a question: why not adopt Ceph instead? Why does either have to be adopted *instead* of the other? They're both admirable pieces of work, with slightly different strengths. The technology in Ceph (e.g. RADOS, CRUSH) is slightly more advanced, and it would generally be a great choice for anyone looking for a solution in the traditional distributed-filesystem space. On the other hand, when it comes to a *cloud* filesystem specifically and the features that implies, I think the modular architecture of GlusterFS carries much greater weight. That provides several significant advantages. * It allows functionality to be added without perturbing a core which many users already depend on. * It moves functionality out to where needed library support (e.g. for auth/crypto) already exists, without tedious interfaces and brittle coupling between kernel and user-space components (e.g. mountd, lockd, gssd). * It moves functionality with high memory requirements (e.g. maintaining long "patch" lists for multi-site replication) or long sequential control flows out of the kernel where such things don't belong. * It accelerates development by avoiding the endless churn in the VFS and block layers, and by making more development tools available. I'd estimate that development for something like multi-site replication would take two to four times as long on a Ceph base, so I'd be proposing it as a feature for Fedora 18 instead. ;) Even if the goal were to implement CloudFS in the kernel eventually, I'd do it in user space first to get all the protocol stuff sorted out before dealing with low-level implementation issues. I have every intention to continue supporting and recommending both Ceph and GlusterFS/CloudFS for their respective use cases, as I consider them quite complementary. _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
