One of the main differences between DMFS and other migration file systems (such as RASHFS, the NAStore 2 file system, or HighLight[3]) is that it is a layered file system. These other file systems merge the data migration code into the file system code, while DMFS uses the layered file system formalism to place its migration code between most kernel accesses and the underlying file system.
We perceived two main advantages and one potential disadvantage with this design choice. The first advantage we perceived is that it would be much easier to create and maintain a layered file system with data migration facilities than to add those facilities to a specific file system and maintain them over the long term. For instance, the Berkeley Fast File System (FFS)[4,5] is undergoing change with the addition of soft updates[7]. By maintaining the file migration functionality separately, we decouple DMFS from any other FFS-related development. Secondly, we leave the choice of underlying file system to the site administrators. If the access patterns of a site are better suited to the Berkeley Log-structured File System (LFS)[4,6], then a site can use that as the underlying file store rather than LFS. The only limitations are that the underlying file system support vnode generation numbers, and the current metadata database requires knowledge of the maximum number of vnodes at the time of initial configuration.
The one potential disadvantage is that the use of layered file systems incurs a certain amount of overhead for each file system operation. In [2], Heidemann measures layered file system overhead to be on the order of a few percent. Section 7 will describe the limited testing we have done to date. The conclusion we have reached is that any performance penalties due to layered file system technology are certainly worth the benefits in maintainability and flexibility.