Hello Jan Blunck,

Jan Blunck:
quoted text
> I start sending out the patches in multiple chunks because nobody reviewed the
> union mount series except for coding style violations. So this is the prework
> for the changes that come with my union mount series. So they are related
> but not a part of the union mount patch series. It seems that people tend to
> like the patch series with small changes for itself instead of a big fat
> series.

I've read your union mount code which was posted on the end of last
July. Here is a comment which is I remember now.

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.

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.


Junjiro Okajima
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html