Hi there, After a good journey working on having an initial /System/Index prototype, I was able to test most of all union filesystems. More specifically, UnionFS, FunionFS, Aufs and Unionfs-Fuse were all tested and stressed, and I came to a decision of not using any kind of union magic for now.
All of those filesystems are very good in doing a union mount of a read-only dir with another one. Some problems arose, though, and I really think it's not a good idea to keep polluting our scripts with heuristics and workarounds to fix them. They are: - Inability to check where a file comes from (our 'which' wrapper). UnionFS has an utility called 'unionctl', where one can ask from which directory used in the mount command a given file comes. This doesn't work fine under chroot, however, since the returned path is the one from outside the chroot. Doing extra processing to try to correctly convert that pathname is overkill and very error prone. - Inability to use an union mount point as input to create another union-mount. One has to use the unioning facilities to ask what dirs compose that mount, and then take that input to create the new mount's argument list. Again, this is complicated under chroot, which is now the only place where this feature was going to be used. - Union-mounts are sometimes dangerous, especially when using ChrootCompile and binding local programs with --local-programs. If the script is aborted and that isn't caught by the traps (this can happen when another scripts are called from inside it), the Area kept for debugging purposes mirrors many base programs from the real filesystem. It's no good to remove it without first checking /proc/mounts... Some union alternatives allow one to choose 'rm' behavior, but this is not mandatory on all implementations. - Kernel implementations doesn't deal very fine with cache coherency, leading to potential data loss. This means that if one creates a union from /Programs/*/Current at /System/Index, one is not able to modify files directly at /Programs anymore. While Aufs solves this by using inotify internally, it still suffers from the problems listed above. So, instead of losing more time and commiting workarounds here and there, I'm taking a more conservative alternative, using symlinks at /System/Index instead. This only requires a simple addon to LinkOrExpandAll.c so that it always expands directories, avoiding problems like writes to a directory represented by a symlink to another program ending up going to that program's dir in the leftovers area. Since I won't be able to dedicate too much time anymore on this for the next weeks, it seems pretty reasonable to keep a more simple, yet functional, implementation. I'll be commiting the patches tomorrow in the day. A new entry in the wiki for developers are going to be written too, in the hope that documenting how scripts work brings more people to the development. Thanks for all your feedback on this, -- Lucas powered by /dev/dsp _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
