[Gluster-users] Fuse vs NFS

Vijay Bellur vbellur at redhat.com
Sat Jul 20 06:42:32 UTC 2019


On Thu, Jul 18, 2019 at 1:06 AM Sudheer Singh <sudsingh at cs.stonybrook.edu>
wrote:

> Hi ,
>
> I was doing perf testing and found out fuse mount much slower than NFS
> mount. I was curious to know what community recommends, mount volumes as
> fuse or NFS?
>


Performance depends on several factors like:

1. Network latency between clients & servers
2. Caching on the client-side
3. Total number of context switches and memory copies between kernel and
userspace.
4. Workload that is being exercised on the mount point.
5. Resources on the client & servers.

It is to be noted that with FUSE, the client talks to servers directly and
in the case of NFS client, the requests reach the gluster servers through
the NFS server which acts as a gateway. Hence for most operations that
bypass the cache (client side cache or cache in NFS sever), NFS will have
one more network hop than FUSE. If the context switch and memory copy
overheads are lesser than the latency added by the additional network hop
with NFS, FUSE will be faster than NFS. Typically for workloads that
perform large sequential writes or reads (> 64 KB block size), you would
expect the performance to be better in FUSE. For writes with small record
sizes and some metadata operations that can be answered by cached content,
NFS can be faster. Also to note is that with FUSE, replication,
distribution, erasure coding etc. happen on the client. With NFS, all these
functions happen on the server. So, the hardware resources available on
client & servers also have a bearing on overall performance.

Hence, in essence, the performance that you get from gluster is not just
dependent on the access protocol but also on other factors like the ones
alluded above.

Thanks,
Vijay

--
> Thanks,
> Sudheer
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190719/2982de94/attachment.html>


More information about the Gluster-users mailing list