Hey Nils everyone
Finally getting around to answering Nil's mail properly - only a month
late! I thought I'd also let everyone else know what's been going on
with the service, since 0.10 released in January this year.
On Tue, 2008-06-24 at 14:40 -0700, Nils Goroll wrote:
first of all: Tim, thank you very much for your very useful auto-snapshot
script.
I believe this really is what every ZFS user needs.
Glad you like it!
As a laptop user, I wanted to make sure that I get snapshots taken even if my
machine is down every night, so I added at scheduling support to
zfs-auto-snapshot,
where each job re-schedules it's next execution, thus ending up with a
cron-like
behaviour.
Okay, after careful consideration, I don't think I'm going to add this
into the code. I absolutely understand the reasoning behind it, but in
cases where you're powering down a laptop overnight, you don't want to
just take a load of snapshots after you power on for every missed cron
job, you just want one (assuming your laptop hasn't magically changed
data-on-disk while it was asleep!)
The other thing that worries me about this, is that it exposes the user
to too much implementation detail: users would need to know about at(1)
timespecs, so for the same reason I didn't add support to allow people
to add their own crontab time strings, I'm not sure this is good either.
All that said, the idea of missing the dates when the cron job fires,
and somehow doing something about it is a good one - so instead, I think
we should add a new zfs/interval property value: none. In the
manifest, instead of setting the interval to be hours, months,
days, minutes - setting none would mean that a cron job wouldn't
be scheduled for that instance of the service.
Why's that good ? Well, then other scripts, events, etc. could still
manually fire the method script, eg:
$ /lib/svc/method/zfs-auto-snapshot
svc:/system/filesystem/zfs-auto-snapshot:login
which would cause snapshots to be taken, under the policies set down by
that instance.
Perhaps you'd like them to fire on login to a desktop, or booting your
laptop, connecting to a network - really whatever event you think is
interesting.
This would mean you'd still get all the functionality the service
provides (rolling snapshots, off-site send/recv, avoiding scrub (though
that bug's fixed now)) and you can control which filesystems get
included in that instance as usual via the // zfs/fs-name property,
or hard-coding them in the instance itself.
As for the other changes you suggested, I've already put some slightly
better svcprop caching code in, but just not your implementation
( something about the block comment:
## NOTE/WARNING: THIS IS NOT GUARANTEED TO BE PORTABLE
## TO OTHER SHELLS ! Depends on whether your shell runs
## the while loop in a subshell or not !
made me a bit nervous! :-) I think the implementation I've got is
okay, bit I'm still testing it.
The other changes that will appear in 0.11 (which is nearly done) are:
* changing way the default // fs-name works - I decided to make the
default instances that use this feature always snapshot recursively,
for performance reasons.
In my day-to-day use, whenever I'm using this feature, I nearly
always end up snapshotting all child filesystems. So, the canned
instances now set the zfs/snapshot-children property. When
searching for filesystems that should be snapshotted, we only
consider ones that have a locally-set property, rather than
inherited one. The down side of this, is that if a filesystem
further down the hierarchy sets com.sun:auto-snapshot=false,
it'll still get included in the snapshots, because of the recursive
flag. Turning off zfs/snapshot-children will get back to the
old behaviour where we manually walk the dynamically generated list
of filesystems to snapshot. It's slow for large numbers of children.
 * Slightly saner preinstall/postremove scripts (though they still
suck)
 * Better shell style - I figured if I'm aiming to get this into ON
someday, I might as well clean up the code now
* Bugfix reported by Dan on March 13, 2008 at 02:29
http://blogs.sun.com/timf/entry/zfs_automatic_snapshots_0_10#comment-1205418551000
* RBAC - I've been annoyed for a while that the service runs as root
all the time and since my new day-job is actually requiring me to
read up on RBAC anyway, I figured now's a good time to have it do the
right thing.
On first look, I was thinking of creating a ZFS Automatic Snapshot
profile and a default user (or role? can roles run cron jobs ?),
which would have similar abilities as the ZFS File System
Management profile, but would also allow the user to stop/start the
service, and run a given script which would do backups. I'm still
reading up on RBAC, so the above may change!
Finally, in terms of wider exposure of this service - I'm talking to
some OpenSolaris desktop guys about
