On Tue, Mar 19, 2013 at 10:24 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > it still might make sense to implement > something as a layer, but some parts of that sucker may be better off as > fs primitives. Hell, we could, in theory, implement xattrs as a layer; > just look at how reiserfs had done them. We could do the same for hardlinks > (look at qnx4, if you wish to see that hack). Of for symlinks (sysvfs). > Or for opened-and-unlinked files (sillyrename could be done as a generic > layer). Or for permissions/ownership/arbitrary names (umsdos, and that > _was_ very similar to layering). It's just that often an underlying fs > has a better way of doing that. IMO whiteouts are in that class. My gut feeling is that whiteouts (and all that's related) are just too specialized. All the examples you listed are more general purpose. I know one that could be useful for a variety of things, an "exchange" operation. While similar to rename, the semantics are much cleaner and so the implementation becomes easier as well. But that one doesn't quite solve the rename-with-whiteout thing. For that a three way permutation would be needed where one of the three is an unlinked "floating" object. That one is a really generic op but we'd need to introduce linking unlinked objects into the tree which comes with its own problems. But I think it may be worth trying to come up with something more generally useful before adding whiteouts and various overlay-specific flags to filesystem code. Thanks, Miklos -- 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