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

Reply via email to