In message <20091117194300.GD17822@shell>, Valerie Aurora writes: [...] > That's my feeling too. I don't see anyway to cleanly implement > fallthrus (or whiteouts) without explicit support from the file system > on the writable layer. Fortunately it doesn't take much support. > > -VAL So, if understood you right, these symlinks are an optimization to simplify and improve the performance of rename()s in r-o layers. Ok. And, people prefer to avoid self-referencing symlinks so as to prevent breaking some userland code that might depend on it. But, this does *not* then eliminate the need to have whiteouts supported in every major f/s that can serve as the writeable layer, right? You still need those. 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(). Erez. -- 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
