On Mon, 8 May 2006, Bill Sommerfeld wrote:
> I think there may be a middle ground here -- provide some relatively
> simple policy-independent mechanisms in the filesystem to allow admins
> to implement the snapshot/backup management policy of their choice.
>
> I can think of a couple mechanisms which would help:
>
> - additional admin-defined filesystem properties, giving the
> administrator a place to store properties such as snapshot frequency,
> lifetime, and backup policy/parameters; these could be maintained in a
> separate database or file, but that is likely to get out of synch with
> the pool so better that they're kept in the pool itself..
The more general case would provide a generic way to store and retrieve
user defined tag/value pairs that are associated (and stored) with the
underlying zfs pool.
> - notifications when pool free space crosses low and high water marks
> so a daemon wouldn't have to keep polling free space to decide when to
> reap expired snapshots.
>
> An optional daemon process which does time-based snapshots and snapshot
> expiration based on the above mechanisms could then be used at many
> sites as-is, while sites with more complicated requirements could modify
> or replace that daemon to implement their site's policy.
+1
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
