On 24 apr 2010, at 16.43, Richard Elling wrote: > I do not recall reaching that conclusion. I think the definition of the > problem > is what you continue to miss.
Me too then, I think. Can you please enlighten us about the definition of the problem? >> The .snapshot directories do precisely what you would want them to do. >> Which is: The .snapshot directory belonging to a parent contains a copy of >> the filesystem as it looked at the time of the snapshot. But when you mv or >> rename a subdirectory, then the .snapshot subdir of the subdirectory >> correctly maps, to preserve the snapshots inside that directory. > > Agree, but the path is lost. In what way? On 24 apr 2010, at 09.18, Brandon High wrote: > To answer the question you linked to: > .shapshot/snapname.0/a/b/c/d.txt from the top of the filesystem > a/.snapshot/snapname.0/b/c/d.txt > a/e/.shapshot/snapname.0/c/d.txt > a/e/c/.snapshot/snapname.0/d.txt I really don't understand what you mean, I think the path is there just fine, and IMHO pretty much in the way you would expect. >> Make sense? > > Yes. The contents of the directory are there, but the full pathname does > not follow because you changed a name in the path. Whether this is > useful or not depends on whether you expect the path to be followed. > > It seems, the NetApp snapshot is a directory-level snapshot rather than a > file system snapshot. I cannot see how to merge the two, so perhaps > adding such a feature to ZFS could not leverage the file system snapshot? I believe NetApp snapshots are volume based in a fashion very much like zfs volume snapshots. /ragge _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
