On Tue, Nov 17, 2009 at 03:20:58PM -0500, Erez Zadok wrote: > 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. Yes. The tradeoff is namespace pollution vs. some new code, and the consensus is pretty firmly against namespace pollution. > 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. -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
