|Subject:||Re: [Gluster-devel] Multiple NFS Servers (Gluster NFS in 3.x, unfsd, knfsd, etc.)|
|Date:||Wed, 06 Jan 2010 21:26:32 +0000|
|User-agent:||Thunderbird 220.127.116.11 (X11/20090625)|
Martin Fick wrote:
--- On Wed, 1/6/10, Gordan Bobic <address@hidden> wrote:With native NFS there'll be no need to first mount aglusterFSFUSE based volume and then export it as NFS. The wayit has been developed is thatany glusterfs volume in the volfile can be exportedusing NFS by addingan NFS volume over it in the volfile. This issomething that will becomeclearer from the sample vol files when 3.0.1 comesout. It may be worth checking the performance of that solution vs the performance of the standalone unfsd unbound to portmap/mountd over mounted glfs volumes, as I discovered today that the performance feels very similar to native knfsd and server-side AFR, but without the fuse.ko complications of the former and the buggyness of the latter (e.g. see bug 186: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=186 - that bug has been driving me nuts since before 2.0.0 was released) I'd hate to see this be another wasted effort like booster when there is a solution that already works.I don't think it would be wasted if it includes NLM since unfsd does not do locking!
Arguably it just replicated the functionality of server side volume assembly and exporting just the assembled volume. Whether the end client connects via nfs or glfs is largely immaterial for the sake of installing an additional package on the client. The bug mentioned above that shows up under that scenario, however, is probably a far more critical issue than what the client connection protocol is. I've said this before - stability should come before features, especially when features are replicating what can already be achieved with only superficial differences.
|[Prev in Thread]||Current Thread||[Next in Thread]|