From: Han-Wen N. <ha...@gm...> - 2012-03-19 16:34:00
|
On Mon, Mar 19, 2012 at 11:17 AM, Miklos Szeredi <mi...@sz...> wrote: > Goswin von Brederlow <gos...@we...> writes: > >> Han-Wen Nienhuys <ha...@gm...> writes: >> >>> Hi there, >>> >>> I am trying to understand under what circumstances FUSE may FORGET inodes. >>> >>> When running >>> >>> ./zipfs -debug /tmp/x /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/src.zip >>> >>> and doing >>> >>> find /tmp/x >>> >>> I notice that the live inode count goes up to 1114. Then, a >>> >>> echo 3 > /proc/sys/vm/drop_caches >>> >>> makes the inode count drop to 96. When I umount the FS, these last >>> inodes get duly forgotten, but can't they be forgotten earlier? Since >>> I only ran a find on the mount, there is nothing from userspace >>> holding on to any data. >> >> No idea. What if you drop caches again? >> >>> Background: I have a file system being used in production that is >>> using too much memory for inodes if any process tries to scan the >>> mount. Are there ways to make FUSE recollect inodes more aggressively, >>> or is there a way to tune the behavior? If not, I could imagine that >>> the daemon could issue some sort of NOTIFY to trigger a forget event. >>> > > Also if you are using the high level library please try the latest git > version of fuse which contains some improvements to the memory > management. This means that when FORGET is sent by the kernel (which it > should do when memory is low) then libfuse should be able to free memory > for its cache better. This is with go-fuse. Which commits are the ones improving the memory management? -- Han-Wen Nienhuys - ha...@xs... - http://www.xs4all.nl/~hanwen |