Anyone know of any reason why I shouldn't be able to use
generic_delete_inode() for the drop_inode() method? Several other
filesystems use it this way and it controls the inode cache in a much
more friendly (system wise) manner.
Unless, something is not working right here, unionfs inodes can grow to
a tremendous number on really active unions. I reached to well over 150
thousand when using the fsstress program from the Linux Test Project.
The inodes do get freed when the union is unmounted or if you use
/proc/sys/vm/drop_cache to get rid of them, so that tells me that they
aren't really leaking and they just seem to be getting moved over to the
free inodes list (according to /proc/sys/fs/inode-nr).
However, using generic_delete_inode() for the drop_inode() method allows
the unionfs inode cache to maintain at a much more reasonable
level...more along the lines of the underlying filesystems.
So far it seems to be working out just fine, but I thought I'd ask.
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
