On Monday 23 November 2009, Valerie Aurora wrote: > > BTW, we might try to figure out a way to use these symlinks to optimize any > > copyup that's not strictly necessary. A rename() doesn't change the file's > > data, hence this symlink idea is suitable. But also, there are other > > meta-data changes to a file which don't affect its data (chmod, chown, > > chgrp, etc.), for which a symlink would be suitable. This would require > > that we could easily change the meta-data of the symlink itself, and return > > that metadata in the upper inode, while using the lower file's data for > > read(). > > I like this idea. Copying up the file's data in chown(), etc. is an > enormous pain and hard to work into the existing code path. It might > be possible to do with this with the directory entry-based approach as > well. I guess we can even support strict atime updates with that, which would be even more painful to do with copyup because they happen more frequently than other inode changes. AFAIK the consensus for other union mount implementations was always that strictatime cannot be sanely done, or not done persistantly. Arnd <>< -- 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
