Nicolas Williams wrote:
On Wed, May 03, 2006 at 01:58:10PM -0400, Bill Sommerfeld wrote:
On Wed, 2006-05-03 at 13:40, Nicolas Williams wrote:
On Wed, May 03, 2006 at 01:32:27PM -0400, Bill Sommerfeld wrote:
5) I assume that new zfs and zpool subcommands will need to specify
whether or not they create a zpool history entry; is there a general
rule here going forward? Working backwards from your list of "logged"
vs "not logged", how about:
- A command which could cause a permanent change to the configuration
of the pool MUST be logged.
- Events which are operationally interesting (such as the start of a
scrub) MAY be logged.
And since the latter may be common, maybe old items should be pruned.
That's in the proposal already:
What I meant is that events that "cause a permanent change..." should
not be deleted from the circular log if there are "old" (older?)
"operationally interesting" events that could be deleted instead.
I.e., if the log can keep only so much info then I'd rather have the
history of a pool's configuration than any but the most recent scrub/
resilver operations.
That perhaps should be implemented as two logs - then the kernel
wouldn't have to read in the buffer & parse it when its trying to just
log a command. One log for modifying subcommands, one log for
internal/interesting events. Makes me squeamish to have two (or more)
though.
eric
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
