On Fri, Jun 01, 2007 at 02:09:55PM -0700, John Plocher wrote:
> eric kustarz wrote:
> >We specifically didn't allow the admin the ability to truncate/prune the
> >log as then it becomes unreliable - ooops i made a mistake, i better
> >clear the log and file the bug against zfs ....
>
> I understand - auditing means never getting to blame someone else :-)
>
> There are things in the log that are (IMhO, and In My Particular Case)
> more important than others. Snapshot creations & deletions are "noise"
> compared with filesystem creations, property settings, etc.
But clone creation == filesystem creation, and since you can only clone
snapshots you'd want snapshotting included in the log, at least the ones
referenced by live clones. Or if there was a pivot and the old fs and
snapshot were destroyed you might still want to know about that.
I think there has to be a way to truncate/filter the log, at least by
date.
> This seems especially true when there is closure on actions - the set of
> zfs snapshot foo/[EMAIL PROTECTED]
> zfs destroy foo/[EMAIL PROTECTED]
> commands is (except for debugging zfs itself) a noop....
Yes, but it could be very complicated:
zfs snapshot foo/[EMAIL PROTECTED]
zfs clone foo/[EMAIL PROTECTED] foo/bar-then
zfs clone foo/[EMAIL PROTECTED] foo/bar-then-again
zfs snapshot foo/[EMAIL PROTECTED]
zfs clone foo/[EMAIL PROTECTED] foo/bar-then-and-then
zfs destroy -r foo/[EMAIL PROTECTED]
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
