----- Original Message ----- > From: "Danny Al-Gaaf" <danny.al-g...@bisect.de> > To: "Csaba Henk" <ch...@redhat.com>, "OpenStack Development Mailing List (not > for usage questions)" > <firstname.lastname@example.org> > Cc: ceph-de...@vger.kernel.org > Sent: Wednesday, March 4, 2015 3:26:52 PM > Subject: Re: [openstack-dev] [Manila] Ceph native driver for manila > > Am 04.03.2015 um 15:12 schrieb Csaba Henk: > > ----- Original Message ----- > >> From: "Danny Al-Gaaf" <danny.al-g...@bisect.de> To: "OpenStack > >> Development Mailing List (not for usage questions)" > >> <email@example.com>, ceph-de...@vger.kernel.org > >> Sent: Sunday, March 1, 2015 3:07:36 PM Subject: Re: > >> [openstack-dev] [Manila] Ceph native driver for manila > > ... > >> For us security is very critical, as the performance is too. The > >> first solution via ganesha is not what we prefer (to use CephFS > >> via p9 and NFS would not perform that well I guess). The second > >> solution, to use > > > > Can you please explain that why does the Ganesha based stack > > involve 9p? (Maybe I miss something basic, but I don't know.) > > Sorry, seems that I mixed it up with the p9 case. But the performance > is may still an issue if you use NFS on top of CephFS (incl. all the > VM layer involved within this setup). > > For me the question with all these NFS setups is: why should I use NFS > on top on CephFS? What is the right to exist of CephFS in this case? I > would like to use CephFS directly or via filesystem passthrough.
That's a good question. Or indeed, two questions: 1. Why to use NFS? 2. Why does the NFS export of Ceph need to involve CephFS? 1. As of "why NFS" -- it's probably a good selling point that it's standard filesystem export technology and the tenants can remain backend-unaware as long as the backend provides NFS export. We are working on the Ganesha library -- https://blueprints.launchpad.net/manila/+spec/gateway-mediated-with-ganesha with the aim to make it easy to create Ganesha based drivers. So if you have already an FSAL, you can get at an NFS exporting driver almost for free (with a modest amount of glue code). So you could consider making such a driver for Ceph, to satisfy customers who demand NFS access, even if there is a native driver which gets the limelight. (See commits implementing this under "Work Items" of the BP -- one is the actual Ganesha library and the other two show how it can be hooked in, by the example of the Gluster driver. At the moment flat network (share-server-less) drivers are supported.) 2. As of why CephFS was the technology chosen for implementing the Ceph FSAL for Ganesha, that's something I'd also like to know. I have the following naive question in mind: "Would it not have been better to implement Ceph FSAL with something »closer to« Ceph?", and I have three actual questions about it: - does this question make sense in this form, and if not, how to amend? - I'm asking the question itself, or the amended version of it. - If the answer is yes, is there a chance someone would create an alternative Ceph FSAL on that assumed closer-to-Ceph technology? Cheers Csaba __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev