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
