Exactly, I mounted the volume in a no-brick
node(nodeB), and nodeA was the server. I have set
different timeout, but when I excute "ls
/mnt/glusterfs(about 3 million small files, in other
words, about 3 million dentries)", the result was the
same, memory usage in nodeB didn't change at all while
nodeA's memory usage was changed about 4GB!
On 09/02/2016 05:42 AM,
Keiviw wrote:
Even
if I set the attribute-timeout and entry-timeout to
3600s(1h), in the nodeB, it didn't cache any
metadata because the memory usage didn't change. So
I was confused that why did the client not cache
dentries and inodes.
If you only want to test fuse's caching, I would try
mounting the volume on a separate machine (not on the
brick node itself), disable all gluster performance
xlators, do a find.|xargs stat on the mount 2 times in
succession and see what free(1) reports the 1st and
2nd time. You could do this experiment with various
attr/entry timeout values. Make sure your volume has a
lot of small files.
-Ravi
在 2016-09-01 16:37:00，"Ravishankar N"
<ravishankar@xxxxxxxxxx>
写道：
On 09/01/2016 01:04
PM, Keiviw wrote:
Hi,
I have found that GlusterFS
client(mounted by FUSE) didn't cache
metadata like dentries and inodes. I have
installed GlusterFS 3.6.0 in nodeA and
nodeB, and the brick1 and brick2 was in
nodeA, then in nodeB, I mounted the volume
to /mnt/glusterfs by FUSE. From my test, I
excuted 'ls /mnt/glusterfs' in nodeB, and
found that the memory didn't use at all.
Here are my questions:
1. In fuse kernel, the author set
some attributes to control the time-out
about dentry and inode, in other words, the
fuse kernel supports metadata cache, but in
my test, dentries and inodes were not
cached. WHY?
2. Were there some options in
GlusterFS mounted to local to enable the
metadata cache in fuse kernel?
You can tweak the attribute-timeout and
entry-timeout seconds while mounting the volume.
Default is 1 second for both. `man
mount.glusterfs` lists various mount options.
-Ravi
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
