Neil Brown wrote: > I tried to come up with a model which is a generalisation of the "old" > behaviour, and provides agreeable semantics for new behaviours. > This is what I came up with: > > A "mount" is an ordered list (pile) of directories. > One of these elements is the "mountpoint", and it is particularly > distiguished because ".." from the "mount" goes through ".." of the > "mountpoint". ".." of all other directories is not accessable. > > Each directory in the pile has two flags (well, three if you count > IS_MOUNTPOINT). > > IS_WRITABLE: You can create things in here. > IS_VISIBLE: You can see inside this. > > Thus, a traditional mount has two directories in the pile. > The bottom one IS_MOUNTPOINT > The top one IS_WRITABLE|IS_VISIBLE oooooh, aren't we in danger of reducing McVoy's semantic gap between theory and practice here? This model is simple enuff to do right the first time, rather than propagating broken semantics which we fix later :-) i *like* it. a simple (3 bits) generalisation, which leaves trad-mount, union-mount (whichever flavour you'd like it to be) and the null-fs as corner cases. this would provide a nice toolset for all sorts of interesting filesys widgets, some of which (autofs, devfs) can be simplified when they take advantage of this infrastructure. What can we do with this? The interesting case is of course creation, and the uppermost-IS_WRITEABLE case can handle all possibilities, with a few tricks: - for laying *additions* or *updates* over a readonly base filesystem, it just works, with no additional policy modules required. - for laying additions/updates/*deletions* over a base filesystem, we also need a -ve entry for objects which have been removed, and a method of ensuring their lookups fail (persistent absence?). - for "interesting" mappings like autofs or devfs, which make policy decisions on lookup+creation, but create *onto* underlying namespaces, union mount can keep the policy and persistence layers separate, with a dumb, persistent base filesys overlaid by a policy-only filesys which is almost stateless (has dcache state, but no persistent storage) so how do we handle revoked entries in a union-mount of rw over ro? - nail down a -ve dcache entry (yuk, no longer pruneable, no longer a cache, ok for autofs' handful of -ve entries, but not scaleable) - magic entries in a mounted-with-IS_MAGIC layer, which have some definitive i-am-not-here property which aborts the lookup, and evades readdir? maybe symlinks to "__ENOENT__" return ENOENT under IS_MAGIC mountflag? - mounting "nullfs" over revoked nodes (is mounting over non-directories actually broken or just deprecated? is it too expensive?) - union-mount *another* filesys with a new flag IS_NEGATIVE, which contains a zero-length file for each file-or-directory which is to return ENOENT. This is more of an "intersection mount" than a union mount, and avoids the namespace-pollution aspect of IS_MAGIC. This little negative-fs would be best implemented as a loopback mount. if you want some more complex policy, just mount a policy-only filesys on top of the pile, which advertises itself as IS_WRITEABLE, but actually arranges creation in some dynamically-determined way, creating entries in whichever lower filesys its policy dictates. Autofs and devfs work this way, and this could provide a generic toolset for such vfs magic. I feel most of the feathers flying in the devfs wars were (are still) about the duplication of vfs functionality, where generalisation of available mechanisms could give it better tools, and result in a much smaller footprint. I'm not arguing for *complexifying* Al's work, or Neil's model, just playing with it as a toolset to see what's missing. Conclusion: Nothing. All more complex interactions are better done using separate policy-only mini-fs layers on top of this (addressing removal from namespace, selection from multiple matches, regexp entries for matching name classes, etc), and many can be exported into userspace via autofs maps. Attempting to clutter this union-fs model with extra bits for use by one or more policy-modules will probably make it sub-optimal for use as a tool by others. ^..^ (00)
