On Jun 1, 2007, at 2:09 PM, 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.

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....

Looking at history.c, it doesn't look like there is an easy
way to mark a set of messages as "unwanted" and compress the log
without having to take the pool out of service first.

Right, you'll have to do any post-processing yourself (something like a script + cron job).

eric

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to