Any rough idea of performance or memory savings (even in something
artificial like dbench run)?
On Tue, May 25, 2010 at 2:24 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> The standard behavior for drop_inode is to delete the inode when the
> last reference to it is put and the nlink count goes to 0. This helps
> keep inodes that are still considered "not deleted" in cache as long as
> possible even when there aren't dentries attached to them.
>
> When server inode numbers are disabled, it's not possible for cifs_iget
> to ever match an existing inode (since inode numbers are generated via
> iunique). In this situation, cifs can keep a lot of inodes in cache that
> will never be used again.
>
> Implement a drop_inode routine that deletes the inode if server inode
> numbers are disabled on the mount. This helps keep the cifs inode
> caches down to a more manageable size when server inode numbers are
> disabled.
>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ---
> fs/cifs/cifsfs.c | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index 78c02eb..8f647db 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -473,13 +473,23 @@ static int cifs_remount(struct super_block *sb, int *flags, char *data)
> return 0;
> }
>
> +void cifs_drop_inode(struct inode *inode)
> +{
> + struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
> +
> + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)
> + return generic_drop_inode(inode);
> +
> + return generic_delete_inode(inode);
> +}
> +
> static const struct super_operations cifs_super_ops = {
> .put_super = cifs_put_super,
> .statfs = cifs_statfs,
> .alloc_inode = cifs_alloc_inode,
> .destroy_inode = cifs_destroy_inode,
> -/* .drop_inode = generic_delete_inode,
> - .delete_inode = cifs_delete_inode, */ /* Do not need above two
> + .drop_inode = cifs_drop_inode,
> +/* .delete_inode = cifs_delete_inode, */ /* Do not need above two
> functions unless later we add lazy close of inodes or unless the
> kernel forgets to call us with the same number of releases (closes)
> as opens */
> --
> 1.6.6.1
>
>
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
