Martin Fick wrote:
--- On Wed, 1/6/10, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
With native NFS there'll be no need to first mount a
glusterFS
FUSE based volume and then export it as NFS. The way
it has been developed is that
any glusterfs volume in the volfile can be exported
using NFS by adding
an NFS volume over it in the volfile. This is
something that will become
clearer from the sample vol files when 3.0.1 comes
out.
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.
Gordan
