[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060801090259.GB10032@X40.localnet>
Date: Tue, 1 Aug 2006 11:03:00 +0200
From: Jan Blunck <j.blunck@...harburg.de>
To: David Howells <dhowells@...hat.com>
Cc: torvalds@...l.org, akpm@...l.org, steved@...hat.com,
trond.myklebust@....uio.no, linux-fsdevel@...r.kernel.org,
linux-cachefs@...hat.com, nfsv4@...ux-nfs.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 30/30] VFS: Destroy the dentries contributed by a superblock on unmounting [try #11]
On Thu, Jul 27, David Howells wrote:
> diff --git a/include/linux/dcache.h b/include/linux/dcache.h
> index 44605be..63f64a9 100644
> --- a/include/linux/dcache.h
> +++ b/include/linux/dcache.h
> @@ -230,6 +230,7 @@ extern struct dentry * d_alloc_anon(stru
> extern struct dentry * d_splice_alias(struct inode *, struct dentry *);
> extern void shrink_dcache_sb(struct super_block *);
> extern void shrink_dcache_parent(struct dentry *);
> +extern void shrink_dcache_for_umount(struct super_block *);
> extern int d_invalidate(struct dentry *);
>
> /* only used at mount-time */
I don't see the point that we need two different versions of
shrink_dcache_sb(). IMHO it is better to fix shrink_dcache_for_umount() so
that it is a replacement for shrink_dcache_sb().
BTW: Talking about shrink_dcache_sb(): is it really necessary to call
shrink_dcache_sb() when remounting a filesystem? The only reason I can see are
changes to the lookup mechanism (hash algorithm etc) but a quick look into the
different filesystems forbid the change of this options during remount.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists