Re: + embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.pa tch added to -mm tree

[Jan Blunck <jblunck@suse.de>]

Junjiro Okajima,

first of all thanks for the feedback on my union mount patches.

On Tue, Nov 06, hooanon05@yahoo.co.jp wrote:

> Whiteouts in your code can be a serious memory pressure, since they are
> kept in dcache. I know the inode for whiteouts exists only one and it is
> shared, but dentries for whiteouts are not. They are created for each
> name and resident in dcache.
> I am afraid it can be a problem easily when you create and unlink a
> temporary file many times. Generally their filenames are unique.

The problem that you describe is only existing on tmpfs as the topmost union
layer. In all other cases the whiteout dentries can be shrinked like the
dentries of other filetypes too. This is the price you have to pay for using
union mounts because somewhere this information must be stored. With ext3 or
other diskbased filesystems the whiteouts are stored on disk like normal
files. Therefore the dentry cache can be shrinked and reread by a lookup.

> Regarding to struct path in nameidata, I have no objection
> basically. But I think it is better to create macros for backward
> compatibility as struct file did.

In case of f_dentry and f_mnt that was easy because you could use macros for
it. Still people tend to be lazy and don't change their code if you don't
force them (or do it for them). Anyway, in nameidata we used dentry and mnt as
the field names. Therefore it isn't possible to use macros except of stuff
like ND2DENTRY(nd) kind of stuff which is even worse.