Those scripts look useful.

FYI: Might also be interested in Tim Foster's automatic ZFS snapshot
scripts:
http://blogs.sun.com/timf/entry/zfs_..._snapshots_0_8

One problem I encountered when taking snapshots of large filesystems
(>100G) is described in this bug report:
http://bugs.opensolaris.org/view_bug.do?bug_id=6509628

The above bug is listed as fixed in a Nevada build but I am running
Solaris 10 update 3 (11/06) and experienced it.
I don't know if it is corrected in s10u4 (8/07) release.

The problem was destroying a snapshot, which is supposed to be fast,
was taking hours as well as using 100% of a CPU.
There is a workaround described in the above bug report which is to
make my current working directory to be inside the filesystem which
was snapshotted, then trying to unmount it The umount will fail
(because the filesystem is in use due to it being my working
directory, if not for other reasons.) But, the side effect is that it
will somehow let the snapshot be destroyed in a reasonable amount of
time (a few seconds) and without the CPU looping.

But, a bad side effect of the workaround I have noticed and which is
not reported in the above bug is that if the filesystem which was
snapshotted is shared by NFS, it becomes unshared as a result of the
attempted umount. That is, even though the umount fails, it causes
the filesystem to be unshared (as if "zfs unshare ..." was run on the
filesystem.) So, it is necessary to run "zfs share ..." after the
umount in order for NFS to continue working.