Junjiro Okajima, first of all thanks for the feedback on my union mount patches.
On Tue, Nov 06, [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
