The most dramatic change needed to get DMFS to work was to get layered file systems working with NetBSD. The layered file system research of Heidemann [2] describes many of the advantages of layered file systems. When we began this work, we found the layered file system implementations present in all *BSDs not to be robust enough for production work. For instance, the NetBSD 1.4 NULLFS certainly will replicate a file hierarchy in another portion of the system's file name space. However simultaneous access of this replication by multiple processes, for instance a parallel make invoked with make -j 8, would result in kernel locking panics. Obviously a production-quality migration system needed a more robust implementation.
The changes described below, especially those of sections 3.3 and 3.4, were implemented at the same time, in addition to a modification to how null_lookup() behaved5. As such, it is not clear which change (if any) was singularly responsible for the increase in robustness, though I suspect the change to how null_lookup() behaves represents most of it.
After these changes were implemented, I performed a few simple tests to ensure their effectiveness. The first one was to perform a multi-process kernel make in a directory on a NULLFS file system (cd into a kernel compile directory and type make -j 8). Before these changes, such an action would promptly panic the kernel. After these changes, it did not. Additionally, simultaneous access of multiple NULL layers and the underlying layer, such as the parallel make above combined with recursive finds in the other layers, have not been observed to panic the system. The DMFS layer we have built based on this NULLFS layer has shown no difficulties (panics or otherwise) due to simultaneous multi-user access in almost one year of operation.
It should be noted that the NULLFS and UMAP layered file systems have benefited from these changes, while the UNION file system has not. It is still not considered production quality.