> Really the only sane way of keeping track of whiteouts seems some external > store. We did an experiment with Unionfs, and moving the whiteout handling > to effectively a "library" that did all the dirty work cleaned up the code > considerably [2,3]. What about keeping track of whiteouts in a special file (or files) in the top level filesystem of the union? For instance, having a /.whiteouts file at the root of the top FS in the stack, instead of storing union-specific data in the flags / inode numbers of the lower levels. This file could also e.g. store the UUID of the lower level FS (if appropriate) so that in subsequent mounts (which might attempt a union with a different lower level branch) you can tell if the whiteouts have meaning. The whiteout history could be flushed by directly mounting the FS and doing rm .whiteouts. This might avoid requiring a store external to the stack of filesystems and I believe it would solve the problem with shared branches and arbitrary stacking that you described? I guess a rather similar effect could be had by somehow storing loopback mountable ODF filesystems in the top layer of a union somewhere (e.g. with the default path /.odf) and allowing the user to specify an alternate location at mount time if necessary. So maybe these approaches are quite similar after all... Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! - 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
