Dear all
I made some tests for a web service using the FUSEX client mount instead of the normal FUSE client. It however looks like that it’s noticeably less performant than the FUSE for reading files. File sizes are 10-100 MB. The response times of requests are roughly at least 5 times higher than for same request types to a server with FUSE client mounts. Did anybody make similar observations? Are there special parameters that could be tried to improve reading speed of FUSEX?
Thanks
Armin
Hi Armin,
the last release has the read-ahead mechanism broken, it does small reads at the moment defined by your network latency. The next tag will be good!
Hi Andreas
is there now a version of FUSEX we could test that should work well?
Thx, Armin
You can use 4.3.12. Cheers Andreas.
Hi Andreas,
We tried fusex v 4.3.12, but it seems that when using it with our 4.2.28 MGM, we get the following bug :
[root@s-jrciprcid87v ~]# mount -t fuse -o fsname=jeodpp eosxd /eosx/jeodpp/
# fsname='jeodpp'
# -o allow_other enabled on shared mount
# -o big_writes enabled
# JSON parsing successfull
# File descriptor limit: 65536 soft, 65536 hard
# Disabling nagle algorithm (XRD_NODELAY=1)
# Setting MALLOC_CONF=dirty_decay_ms:0
[root@s-jrciprcid87v ~]# ls /eosx/jeodpp/home/users
ls: cannot access /eosx/jeodpp/home/users: No such file or directory
[root@s-jrciprcid87v ~]# ls /eosx/jeodpp/home/
groups projects users
[root@s-jrciprcid87v ~]# ls /eosx/jeodpp/home/users
[correct list]
I.e. the local client doesn’t know any file or folder entry until it doesn’t explicitly list all parent folders.
It does it only when using fusex v 4.3.x against server 4.2.x, any other combination works correctly (without changing the configuration file).
Can you confirm this bad behaviour, or could we have some misconfiguration ?