We got this code into nv_100, as part of LSARC 2008/571 and (at least inside Sun, so far) folks
have been starting to play with it.</p

It’s the first time I’ve been able to use the GNOME Nautilus integration that Erwann came up with, and I think it’s pretty cool. Big ups to Niall & Erwann for all their hard work – on helping to get this integrated – without them, this stuff would still just be kicking around on my blog!

We’ve had a few comments so far – most were known bugs and fixed already. I’ll list them here, and add comments as we go along.

Services enabled by default

SUNWzfs-auto-snapshot delivers all it’s instances as disabled, but the
accompanying desktop support, SUNWgnome-time-slider (the desktop service that uses SUNWzfs-auto-snapshot, integrates more tightly with the desktop and monitors disk space) had a postrun script that enables the services out of the box. Just run svcadm disable <service> to disable them if you want to, but see below for more ideas if you just don’t want to snapshot everything

Noisy cron job

There was some changes close to integration that made the home directory for the
‘zfssnap’ role go away, which had impact on the way we were planning on doing
logging. Originally, the cron job
would just echo messages onto the end of the SMF instance’s log file in
/var/svc/log but since the cron job now runs as a non-root user, we aren’t able
to write to those anymore.

So we changed it to write logs to the zfssnap user directory, but that wasn’t good either, so we eventually moved all logging for the cron job
to syslog. A small bug though meant that the service is still a bit too noisy, and so cron end up sending love letters in
in the form of svcprop errors to /var/mail/zfssnap – sorry about that. This was
actually fixed pre-nv_100, but it just missed the integration date.

Details here on how to grab the sources and build your own version of the
SUNWzfs-auto-snapshot package if you want the fix sooner rather than later.

Service inexplicably dropping to maintenance mode

This is probably the most common failure – I’d filed 6749498 about this, which turned out to be a duplicate of
I say “inexplicably”, /var/adm/messages will actually have more detail – as noted above,
I don’t have a way to explain to SMF why we’re dropping the service to maintenance mode, so you just need to look for the log in the right place. Logging during service start/stop gets picked up by SMF, day-to-day log messages (and there’s not many of those) get handled by syslog

Otherwise, a few other words of advice:

The service on startup will arrange to take automatic snapshots of all datasets
on all pools on the system. You can have it not do this by setting a ZFS user
property at the top level dataset in each pool, eg.

$ pfexec zfs set com.sun:auto-snapshot=false rpool

This is a much better way than just disabling the service altogether, this way, you get the option to have the service take snapshots of datasets you are interested in, eg.

$ zfs set com.sun:auto-snapshot=false space
$ zfs set com.sun:auto-snapshot=true space/timf
$ zfs set com.sun:auto-snapshot=false space/timf/foo
$ zfs set com.sun:auto-snapshot:frequent=false space/timf/onnv

Better yet, if you use ZFS Delegation to allow users the userprop permission, they can set user properties on their own filesystems, and choose which of their filesystems get included in the snapshot schedule as above.

Have a look at the hg history, the README for more documentation, and the
auto-snapshot.xml service manifest if you're really interested
in what's going on behind the scenes. Enjoy!