Vincent Régnard a écrit :
Vincent Régnard a écrit :
Vincent Régnard a écrit :
NB: the directory where mismatch are found has a large number of
files (a few tens of thouthands). When I ls in that directory (on
glusterfs mount point); it takes ages to return the answer. There are
also many symlinks in that directory (about 20%).
I saw a stat-prefetch translator that I dont have presently, can this
help in that situation ? Is it a post 1.3.5 functionality ? (1.3.6?)
Upgrading to 1.3.6 avoid loadaverage increase. But behaviour is the
same, client loops indefinitely the same way, same log messages. And
doing a ls on /mnt/glusterfs mount point hangs also indefinitely, a
kill -9 on ls does nothing, pocess is uninterruptible.
Probleme seams to be I was mounting the GFS volume on a mount point on a
file system not having extended attributes. Mounting the volume on a
mouint point where extended_attrs is available seams to work better.
Should'nt we encounter at least a warning when doing such a bad operation ?
More precision, the problem is not having the GFS mounted somewhere, but
accessing the files on this GFS via symlinks path on a FS.
For reasons I dont understand, accessing the files in /home with the
following symlinks is causing the loop problem. If I remove these links,
and access the glusterfs home FS via /mnt/gluster, behaviour is normal.
# ls /home/ -l
lrwxrwxrwx 1 root root 23 Oct 18 09:51 dist ->
/mnt/gluster/home
lrwxrwxrwx 1 root root 12 Oct 18 09:42 ftponly ->
dist/ftponly
This looks like a symlink loop problem.
--
Vincent Régnard
vregnard@xxxxxxxxxxxxxxxx
TBS-internet.com
027 630 5902
