Hello Jan Blunck, Jan Blunck: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
