[Bugs] [Bug 1738878] FUSE client's memory leak

bugzilla at redhat.com bugzilla at redhat.com
Mon Sep 2 20:06:59 UTC 2019


--- Comment #11 from Csaba Henk <csaba at redhat.com> ---
Yes, this is a known phenomenon and basically harmless, if not too frequent.

The effect of the lru-limit patch is that the glusterfs client asks the kernel
to drop those inodes which are found to be inactive for a long time. (The
client can't get rid of them on its own, it needs to keep the inode context as
long as the kernel keeps a reference to them. The kernel indicates to the
glusterfs client when it abandons all references to the inode (this is called
"forgetting the inode"), so this condition shall be known to the client; and
what the glusterfs client can do is to ask the kernel to evict an inode from
caches (this is called "inode invalidation"), which usually implies abandoning
references and forgetting it.)

However, it's a naturally racy situation: by the time the glusterfs client
sends the request to the kernel to invalidate a given inode, the kernel might
have already forgotten it and the reference sent with the invalidation request
is dangling. The kernel provides feedback to the glusterfs client of this
situation by failing the write to /dev/fuse that carries the invalidation
request with errno ENOENT, "No such file or directory".

If this occurs, there is nothing wrong about it in itself. However, if this
scenario proliferates, that's an indication of the glusterfs client getting
overwhelmed by its invalidation requests so that these requests accumulate
faster than they are processed and written to /dev/fuse. This might result in
trashing performance (while being useless in terms of inode footprint
reduction). To overcome this, we introduced a tunable to stop filing
invalidation requests if there number of outstanding invalidation request hits
a threshold.

This is implemented in https://review.gluster.org/23187. Do you think you are
in need of, are you interested in trying this patch?

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Bugs mailing list