eric kustarz wrote:
>
> On Mar 21, 2008, at 2:03 PM, David W. Smith wrote:
>> If you import a zpool you only get the history from that point forward I
>> believe, so you might not have all the past history, such as how the
>> pool was originally created.  Having a way to dump the config for
>> as easy way to recreate is a good feature (as others have mentioned).
>
> Actually that isn't correct.  Its the history of the pool - not since 
> the last import.  It even records the fact that you destroyed the pool 
> :) :
> fsh-sole# zpool history
> History for 'd':
> 2008-03-21.15:28:29 zpool create d c0d0
> 2008-03-21.15:28:32 zpool export d
> 2008-03-21.15:28:35 zpool import d
> 2008-03-21.15:28:38 zpool destroy d
> 2008-03-21.15:28:44 zpool import -D d
> fsh-sole#
>
> I was curious what non-admin induced changes to the pool that Torrey 
> was thinking about.  If its important to remember then we can add 
> internal events to track them.

There are two facets to this. (At least in my head....)

One, is the history of what has happened. A lot of that would be in the 
zpool history but non-admin related events aren't in there. (Are they?) 
I'm thinking things like checksum errors, devices leaving/coming back, 
etc. You can argue that those events would be in the FMA logs or even 
/var/adm/messages but if you want a one stop shop it might be a good 
idea to keep it in the history.

Second, and this is what I was thinking when I weighed in is the current 
state of the pool. There is obviously some overlap between tracking all 
of the events or activities that have occurred in/to the pool. However, 
a command to dump the current state that is easily parsed, could be fed 
to other scripts, used for diagnosis by service folks, etc. would come 
in handy. Think of something the explorer folks would want to run.

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

Reply via email to