> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
