On Apr 21, 2010, at 10:38 AM, Edward Ned Harvey wrote: >> From: Richard Elling [mailto:richard.ell...@gmail.com] >> >>>> What happens when you remove the directory? >>> >>> Same thing that happens when you remove the .zfs directory. You >> can't. >> >> Are you sure I cannot rmdir on a NetApp? That seems like basic >> functionality to me. >> >> Or are you thinking "rmdir dirname/.snapshot" when I'm thinking >> "rmdir dirname; mkdir dirname" which is a common operation >> in a developer environment. Or "mv dirname dirname-old; >> mv dirname-new dirname" which is common when managing >> software upgrades that are not clone-aware. > > I don't see what the confusion is. > > In ZFS: > cd /tank/home/eharvey > mkdir foo > touch foo/bar > sudo zfs snapshot t...@bestsnapshotever > rm -rf foo > ls /tank/.zfs/snapshot/bestsnapshotever/home/eharvey/foo > bar > > In NetApp: > cd /netapp-nfs-mountpoint/home/eharvey > mkdir foo > touch foo/bar > (as root on the netapp) snap create vol0 somesnapshot > (back on my nfs client) > rm foo/bar > ls -l foo/.snapshot/somesnapshot > bar > ls -l .snapshot/somesnapshot/foo > bar > rmdir foo > ls -l foo/.snapshot > foo: No such file or directory > ls -l .snapshot/somesnapshot/foo > bar > > Point is, in Data Ontap, *every* directory has a .snapshot subdirectory. If > you rmdir a directory, then you can find that directory in the .snapshot of > its parent. > > Does that answer it?
So you are saying that the OnTap .snapshot directory is equivalent to a symlink to $FSROOT/.zfs/snapshot? That would "solve" the directory shuffle problem. > Point is, this way you never have to guess how many filesystems are nested > within higher level zfs filesystems, you never have to guess how far up the > tree you need to go, in order to find the correct .zfs subdirectory which > contains the snapshots for your PWD. It's simply more convenient to use > netapp style .snapshot subdirectories instead. Plus, all my users can > remember ".snapshot" but they don't remember ".zfs" or even worse: "Use the > .zfs, but only at the 3rd level of parent directories, to access snaps for > your home, but go one level higher for the snaps of anything outside your > home directory..." > > This is a tiny little point, where netapp is simply better. And I'm sure > there are some other points, but I don't personally care about them as much > as the advantage zfs has over netapp. Namely, installable on normal > hardware, no license fees necessary to snap replicate (zfs send) filesystem > copies all over my world. Snap onto removable disks. Restore using a free > black box, mount it in my laptop, etc etc. > > At present, the workaround I have for zfs is: > ln -s .zfs/snapshot snapshot > This makes the snapshot directory plainly visible to all NFS and CIFS users. > Easy to find every time, easy to remember. Especially important for Mac > cifs clients, because there's no addressbar to type in ".zfs" even if you > knew that's what you want to do. So a cron job with a find will solve the problem, no? -- richard ZFS storage and performance consulting at http://www.RichardElling.com ZFS training on deduplication, NexentaStor, and NAS performance Las Vegas, April 29-30, 2010 http://nexenta-vegas.eventbrite.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss