No matter how you slice it, it's ugly. Maybe even uglier on the client. For every client to have to implement the latest protocols and NFSv4 extensions to get this, may be a bit much to ask (not likely to happen any time soon). In the right light, ZFS itself looks pretty darn ugly, due to layering violations.... To a large extent, aesthetics are a matter of perspective.
When aesthetics gets in the way of something useful enough, maybe it's time to adjust the desired aesthetics, or do something completely different. Maybe this is really a ZFS problem, people want subsets to be like one filesystem. If ZFS allowed you to clone and snapshot individual directories within the same dataset, and NFS to expose parent and cloned children all on the same mount, this would also accomplish what VMware users could use. What would be preferred is backwards-compatible consistent behavior across all NFS clients. I wouldn't call it an easy hack, but it would be enormously useful to many... Who cares what you tell the client the inode numbers of a file are, as long as everything is self-consistent and persistent [across reboots]... Perhaps the fact NFS is implemented in kernel space is part of what's wrong. I don't suppose there's any way of creating a virtual filesystem with a bunch of stitched together filesystems and presenting them as one contiguous directory space, is there? Maybe extend ZFS so you could do something like this: zfs create pool1/a zfs create pool1/b zfs create pool1/c And some method of be provided to create a virtual pool: eg vpool create pool2 virtual pool1/a pool1/b pool1/c Such that filesystem "pool2" is a proxy filesystem that represents the union of these filesystems on pool1, contains its own virtual filesystem space and maps requests to the proper filesystem. And maps from virtual 'inodes' to inodes on the right constitutent filesystems... That could be further generalized into an 'aggregate filesystem', with as many levels of nesting as desired. Then when you shared it with NFS, NFS would see one filesystem; other file sharing protocols that might be created in the future, would also see one file system. There can be no doubt about the admin's intents (when they share an aggregate filesystem, they want to share everything in it, otherwise they wouldn't have included it in the group).. -- This message posted from opensolaris.org
