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
Jan Blunck <[email protected]> wrote:
> IMHO it is better to fix shrink_dcache_for_umount() so that it is a
> replacement for shrink_dcache_sb().
The former may only be used when we *know* there aren't any references
remaining to any of the dentries (as it severely reduces the amount of time
spent holding the dcache_lock). The latter is used in situations in which the
assumptions of the former don't hold true.
Now I could make the former hold the locking a lot more (I had a version of
the patch that did that), but the former destroys all an sb's dentries,
whether or not they're still in use (which they shouldn't be), and the latter
does not.
The latter also doesn't reap the anon list directly; only where anon dentries
are also unused does any anon reaping occur. The former reaps them directly
and forcibly.
So, in conclusion, I don't think you can replace the latter with the former,
and the latter is insufficiently complete to replace the former.
> 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.
If you're just remounting, then not all dentries can necessarily be purged
anyway - some of them may still be open. Consider remounting root for
read-only or read-write...
David