Martin Fick wrote:
--- On Thu, 1/7/10, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
Shehjar Tikoo wrote:
Gordan Bobic wrote:
Martin Fick wrote:
--- On Wed, 1/6/10, Gordan Bobic <gordan@xxxxxxxxxx>
wrote:
I don't think it would be wasted if it
includes NLM since unfsd does not do locking!
It does not do decent security either. One of our
goals is to implement kerberos5 based authentication. We also
want to support NFS over RDMA and NFSACLs. For extending to
these, unfsd code is highly limiting.
So why exactly use NFS instead of GlusterFS with
server-side brick assembly? What is the advantage? I cannot
see one either in terms of performance or functionality.
This is what I would be using if I could get that setup to
work without bugginess (e.g. bug 186) and crashing (see
other emails on this thread, will try to re-create and
provide backtraces).
The last time I evaluated GlusterFS, it did not support
graceful server disconnection/rebooting (i.e. clients with
open files will see errors instead of blocking). While it
would be awesome of this were simply "fixed" at the
GlusterFS level, if the NFS xlator provides this
functionality it would be a big win. This feature is the
single feature keeping me from using GlusterFS to this
day. I look forward to either of theses solutions so that
I could use GlusterFS,
Yes. Gluster NFS server reboots work fine with the NFS xlator.
The other aspect is the disconnections from and reboots of GlusterFS
backends/replicas. That is handled by replicate and distribute
self-heal but I havent yet come around to the cluster availability
tests with NFS yet. Soon..
-Shehjar
-Martin
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
