Mark Shellenbaum wrote: > Kyle McDonald wrote: >> Bill Sommerfeld wrote: >>> On Wed, 2008-02-27 at 13:43 -0500, Kyle McDonald wrote: >>> >>>> How was it MVFS could do this without any changes to the shells or >>>> any other programs? >>>> >>>> I ClearCase could 'grep FOO /dir1/dir2/file@@/main/*' to see which >>>> version of 'file' added FOO. >>>> (I think @@ was the special hidden key. It might have been >>>> something else though.) >>>> >>> When I last used clearcase (on the order of 12 years ago) foo@@/ only >>> worked within clearcase mvfs filesystems. >>> >>> It behaved as if the filesystem created a "foo@@" virtual directory for >>> each real "foo" directory entry, but then filtered those names out of >>> directory listings. >>> >>> Doing the same as an alternate "view" on snapshot space would be a >>> simple matter of programming within ZFS, though the magic token/suffix >>> to get you into version/snapshot space would likely not be POSIX >>> compliant.. >>> >> Ahh. >> >> I suspected it should be 'possible' to code it into ZFS. >> >> The reason it's been left to runat instead seems to be POSIX >> compliance then? > > Yes, we have runat for POSIX compliance. > > An earlier prototype of Solaris extended attributes utilized a /@/ > syntax to enter enter xattr space. For example: > > /data/file1/@/ > /data/file1/@/attr.1 > ... > or > /data/dir1/@/ > > A readdir of /data/dir1 wouldn't show the @ directory, but you could > always request to enter it. > > This violated posix in a couple of ways. One we took away the @ > filename and two you can't have a directory on a file. > > It was a really nice model, and I still kind of wish we could have > integrated it that way. > Why not resurrect the behavior, but default it to off, and leave it to the user to enable with a ZFS filesystem or pool attribute?
-Kyle > -Mark _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
