> From: Tom Limoncelli [mailto:[email protected]] > > On Fri, Apr 23, 2010 at 7:06 AM, Edward Ned Harvey > <[email protected]> wrote: > > My expectation was that these would all be identical: > > > > a/.snapshot/vol0_deleteme/b/c/d.txt > > a/e/.snapshot/vol0_deleteme/c/d.txt > > a/e/c/.snapshot/vol0_deleteme/d.txt > > I agree. > > The issue is that zfs and netapp implement snapshots in entirely > different ways. A zfs snapshot appears at at the root of the file > system (in one pre-defined place, per file system). On a Netapp, the > ".snapshot" directory is a magically thing that exists in every > directory. It doesn't show up in opendir()/readdir() otherwise "find" > would find it over, and over, and over, and over. You'd basically > never finish your find! > > (Ok, opendir()/readdir() does reveal a ".snapshot" entry in some > conditions... like at a mount point). > > These subtle features of NetApp are very nice. When you get your > first netapp it works great, and then you keep discovering nice > touches like this that make you more and more impressed.
Quoi??? I was concluding precisely the opposite. Namely: To have the .snapshot directory in every directory is nice and convenient for user access, but if a user can "mv" some directory and suddenly it's not being backed up anymore, not included in the previous snaps of the parent directory ... I think it sounds like the Netapp implementation is something I would call "broken" albeit more convenient from a user perspective. Personally I choose reliability over convenience any day. Especially when it comes to backups. Which means I'm more and more in favor of ZFS instead of Netapp. _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
