I think a backup solution for a non-plan9 file system (e.g. ZFS) that goes straight to the venti block store (as Bakul suggests) seems like it would be more satisfactory than layering it on top of the plan 9 file system, if there's a practicable way to do that.
In the Glenda and Tux paper the idea was to tunnel communication between a foreign file system client and server through 9P. The protocol was not really designed to be suitable for a storage format. I have had occasion in the past to layer one (UNIX-like) file system on top of another, though: What I did was to create a single file for all the fixed sized metadata (inode table) and have numbered files for the inode file contents. Many file systems and tools don't cope well with very large directories, so I distributed the files over sub directories by breaking up the inode number into digit groups. So e.g. inumber 1234567 becomes d01/d23/d45/f67 in the underlying file system. Inumber 123 becomes d01/f23. Some of the files contained the contents of the upper file system's directories. So this way the metadata and path names of the two file systems are completely separated. This has the nice property that it uses the file implementation of the underlying file system, so is quite simple to implement. I didn't have ACLs or other xattr to worry about, but with deduplication available in the underlying file system that might not be a problem. It might be reasonable to perhaps layer the storage features of ZFS over the Plan 9 file system in this way, though I don't know much about ZFS other than what I've read in wikipedia - it looks pretty intimidating! My worry is that (as with a lot of things) you run the risk of chasing another development team as they add and change things. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Taf5e3581b0a00ee0-Mbcc3476c7e5c452532c0b264 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
