[Gluster-devel] How to enable FUSE kernel cache about dentry and inode?
Ravishankar N
ravishankar at redhat.com
Tue Sep 6 04:35:19 UTC 2016
That is strange. I tried the experiment on a volume with a million
files. The client node's memory usage did grow, as I observed from the
output of free(1) http://paste.fedoraproject.org/422551/ when I did a `ls`.
-Ravi
On 09/02/2016 07:31 AM, Keiviw wrote:
> 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!
>
> 发自 网易邮箱大师 <http://u.163.com/signature>
> On 09/02/2016 09:45, Ravishankar N <mailto:ravishankar at redhat.com> wrote:
>
> 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 at redhat.com>
>> 写道:
>>
>> 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 at gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160906/98f4f1bc/attachment-0001.html>
More information about the Gluster-devel
mailing list