> How does the absense of a read-only file-system affect the ability to > have a union-mount only 'visible' for a specific user or user-process? > Or is this read-only thing necessary to solve another problem? > Essential for the union-mount solution to work, is that it can at > least be *only* visible/available for a given (user) process. Otherwise > your system is less different from a progressive system. Still in that > case, the union-mount solution might have some advantages, like simple > repair, and a backup procedure (unmount the union-mount, or restart the > machine -- assuming you didn't add the union-mount to fstab).
The idea seems to be that you have a "live" version of the host system (real "/", which is mounted read-only and unioned with a copy on write system). Current Darwin only allows .dmg or mounting from an unmounted device. In both cases the underlying system is intrinsically read-only, i.e. the union fs is not really needed. I don't think it is a good idea to unomount / remount read-only your root file system. If you clone a existing installation and mount this, I think you have effectively a progressive system. This approach is mentioned in the entoo-macos bootstrap howto. That the union file system is visible to all processes becomes a secondary problem (I think it just means that you could have only one parallel Gentoo union / chroot) The basic problem with the Darwin unionfs implementation is that you have to have a (read-only) file system in the first place, which you can union to. As far as I understand the Linux version (which may be only a wishlist entry resp. a specification, you can do things like mount folder1 read-only U folder2 read-only U folder 3 read-write (where U is a concatenation operator) The FreeBSD soltuins divides these usecases into the actual union (unionfs), and the mount from a subfolder of a mounted deice (nullfs) Regards Dirk -- [email protected] mailing list
