Hi Tim, > So, I've got a pretty basic solution: > > Every time the service starts, we check for the existence of a snapshot > [...] - if one doesn't exist, then we take a snapshot under the policy set > down by that instance.
This does sound like a valid alternative solution for this requirement if you want to avoid using "at", though this will involve additional complexity for parsing timestamps of existing snapshots and calculating intervals, which I think is not that trivial in shells (consider timezone changes, leap years etc). Also, "at" can express intervals which are not expressible with crontabs, so keeping at schedules as an additional feature could be advantageous - which would be a solution to the shortcoming you have documented in the code: # Adding a cron job that runs exactly every x time-intervals is hard to do # properly. > Hard to please everyone! If you felt like it, it'd be great to get the > "offset" property working - that'd make the use of cron a lot more > flexible for admins I think. OK, I'll let you know when (if) I start working on it so we don't do double work. > Would the conditional-snapshot-on-start-method solution work for you? I think so, on the other hand I don't see why exactly you want to avoid supporting "at" as well. > I've attached some sample code - see what you think. This is basically a simpler version of the same idea - put svcprops in variables. There are a couple of obstacles here: - If you create variables with the names of svc properties, you run into the issue that shell variables cant contain all characters valid for svc properties, which you need to work around then (you are using sed to filter out some characters (e.g. by mapping - to _), but this will make more than one svc- prop onto the same cache entry, which might work for zfs-auto-snapshot, but is not a general solution). My suggested code uses associative arrays which don't have this limitation. - For your solution, how do you invalidate the cache if a property is being changed or deleted (this is trivial, but not yet implemented)? - Does your solution handle white space, quotes etc. in svcprop values properly (I think there is an issue regarding white space, but I have not tested it)? - Does your solution impose a security risk? (consider the eval $NAME) Cheers, Nils This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
