On Tue, Jul 31, 2007 at 06:03:06PM +0100, Mark Williamson wrote: > > 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. What is needed is a "filesystem" that has all the directory bits only. For ODF, we opted to "abuse" existing filesystems to see if it actually helped Unionfs, and I think it did help. Really, now what we (unionfs) need is a cleanup of the ODF code, with a bit better defined interface. ... > 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? We generally did a loopback mount on a file. Very similar to your idea. > 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... Very :) We forced the user to mount the fs in the odf loopback manually, but there's no reason why we couldn't do an in-kernel mount on unionfs mount time. Josef 'Jeff' Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) - 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
