On Mon, Nov 23, 2009 at 07:44:19PM +0100, Arnd Bergmann wrote: > 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. Okay, this seems really worthwhile to try then. It seems like we can, as before, create a per-fs DT_FALLTHRU file type (since we're out of bits for the VFS-level file type). Then, instead of reusing the file systems' "normal" directory entry code, we reuse the symlink code. As an example, with the current code, ext2_fallthru_dentry() is a lot of copy-n-paste from ext2_add_link(); in the new version it would look a lot like or call ext2_symlink(). -VAL -- 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
