I welcome the re-write. The deficiencies of the current snapshot cleanup implementation have been a source of constant background irritation to me for a while, and the subject of a few bugs.
Regarding the issues in contention - the send hooks capability is useful and should remain, but the implementation of it may and probably should be vastly different. I don't think it's a terrible thing if the capability remains, even if it requires some adjustment in the implementation of scripts people have written to make them work in the new world. That blurs the line a little in terms of interface commitment. - I really would like better separation between gui and service, in particular the dependency on a whole garden full of gnomes and X libs. I don't want these on my cut down storage appliance. In general: It seems there's scope and opportunity to separate the taking and removing of snapshots by the service from other actions that may be triggered (send, etc). I don't think you want those hooks executing in the context or process of the service, for a number of reasons. Wouldn't it be better to have some events published on the creation and deletion of snapshots, and a separate service that can listen to those events and trigger hooks and actions (eg. replication, including the established interface) accordingly? In general, why should my snapshot replication mechanism specifically be limited to snapshots triggered by the auto-snapshot svc? I'm also concerned about the sleep interval of the service, which as described sleeps until the next scheduled snapshot. This is all very well in general, except that if I disable some of the shorter-period snapshots (say, only daily and above) I only get daily checks against the space threshold. Room for improvement here. Would there be a way to avoid taking snapshots if they're going to be zero-sized? There's a whole separate set of discussion about whether deleting the 0-size snapshots is a good idea or not, entangled with some of the current implementation issues. However, to avoid unnecessary disk access (power save spin-ups) it would be nice to avoid making snapshots and then deleting them again straight after (and calling hooks on them :-). This probably needs a zfs change for a "discretionary snapshot" only if the fs has changed since the previous one. The rsync project will be a whole separate design effort. It would be nice for this to consider both "backing up zfs snapshots via rsync to remote <other storage>" as well as "backing up remote <other storage> to zfs with snaphots", notionally similar to rsnapshot and other similar implementations. -- Dan. (posted here, rather than in response to the mailing list reference given, because I'm not subscribed and because I never knew that mailing list existed since it's apparently not visible as a web forum). -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
