Gordan Bobic wrote:
Shehjar Tikoo wrote:
----- "Gordan Bobic" <gordan@xxxxxxxxxx> wrote:
I'm not sure if this is the right place to ask, but Google has failed
me and it is rather related to the upcoming Gluster NFS export
feature. What I'm interested in knowing is whether it will be
possible to run Gluster NFS export for glfs mounts while using knfsd
as per standard
for exporting non glfs paths?
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.
The answer to your question is, yes, it will be possible to export your
local file system with knfsd and glusterfs distributed-replicated volumes
with Gluster NFS translator BUT not in the first release.
See comment above. Isn't that all the more reason to double check
performance figures before even bothering?
In fact, I may have just convinced myself to acquire some iozone
performance figures. Will report later.
e.g. if /home is a glfs mounted volume and /usr/src is on a raw block
device, will it be possible to have /home handled by the glfs NFS
export while having /usr/src handled by the native knfsd?
Also, you'll be able to export both using the Gluster NFS server and
not need the knfsd at all but that is irrelevant for you I suppose.
You mean use glusterfsd to export both glfs volumes and raw disk
volumes? Why on earth re-invent unfsd?
It is not re-invention but a consequence of the translator stack
design in glusterfs. Stack the nfs xlator over storage/posix and what
you get is an architecture similar to unfsd's way of exporting local
directories.
-Shehjar
The NFS translator right now does not make it possible for
the knfsd and Gluster NFS to co-exist on the same box(even if the above
options are used) but it is not hard to do and I will include this option
in one of the subsequent releases.
Let me get some iozone figures on unfsd in this new performance enhanced
way vs. server-side AFR glfs client. It may end up saving you some effort.
One possible work-around I can think of is to have one daemon listen
for NFS connections on TCP and the other on UDP, but this is a bit lame.
BTW, we're only supporting NFS over TCP in the upcoming NFS translator.
Hmm... I'm not sure of that's a good thing or a bad thing...
Gordan
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
