zfs discuss - Mar 2007 - Heads up: ''zpool history'' on-disk version change

I just integrated into snv_62:
6529406 zpool history needs to bump the on-disk version

The original CR for ''zpool history'':
6343741 want to store a command history on disk
was integrated into snv_51.

Both of these are planned to make s10u4.

But wait, ''zpool history'' has existed for several months,
aren''t we
revising, um, history here?

It was originally believed that even though ''zpool history''
added
additional on-disk information it didn''t need to bump the on-disk  
version.  My testing verified this to be true.  Turns out my testing  
was incomplete.  There is an edge case where if you have a pool with  
history recorded then you cannot move that pool to a pre-snv_51  
machine if that machine is also a different endianness.  If you do,  
then the load/import of the pool will cause a panic.  Please note:  
there is no corruption here.  If the machine is the same endianness,  
then the load/import will work just fine.

In order to again access your history, you will need to do a ''zpool  
upgrade'', such as:

fsh-hake# zpool history wombat
History for ''wombat'':
cannot get history for pool ''wombat'', pool must be upgraded:  
unsupported version
fsh-hake# zpool upgrade wombat
This system is currently running ZFS version 4.
Successfully upgraded ''wombat'' from version 3 to version 4
fsh-hake# zpool history wombat
History for ''wombat'':
2007-03-19.19:01:55 zpool upgrade wombat

fsh-hake#

If your pool already has history, that data will be preserved and  
retrievable once again after you do the ''zpool upgrade''.

A reminder about ''zpool upgrade'': once you upgrade, the pool
can no
longer be accessed by systems running older versions of ZFS.  Please  
see the zpool(1M) manpage.

If you have any further questions, feel free to send them my way.

controlling the present,
eric

eric kustarz <eric.kustarz at sun.com> writes:
> I just integrated into snv_62:
> 6529406 zpool history needs to bump the on-disk version
> 
> The original CR for ''zpool history'':
> 6343741 want to store a command history on disk
> was integrated into snv_51.
> 
> Both of these are planned to make s10u4.
> 
> But wait, ''zpool history'' has existed for several months,
aren''t we
> revising, um, history here?
> 
> It was originally believed that even though ''zpool
history'' added
> additional on-disk information it didn''t need to bump the on-disk
> version.  My testing verified this to be true.  Turns out my testing  
> was incomplete.  There is an edge case where if you have a pool with  
> history recorded then you cannot move that pool to a pre-snv_51  
> machine if that machine is also a different endianness.  If you do,  
> then the load/import of the pool will cause a panic.  Please note:  
> there is no corruption here.  If the machine is the same endianness,  
> then the load/import will work just fine.
Is this the same panic I observed when moving a FireWire disk from a SPARC
system running snv_57 to an x86 laptop with snv_42a?

6533369 panic in dnode_buf_byteswap importing zpool

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

>
> Is this the same panic I observed when moving a FireWire disk from  
> a SPARC
> system running snv_57 to an x86 laptop with snv_42a?
>
> 6533369 panic in dnode_buf_byteswap importing zpool
Yep, thanks - i was looking for that bug :)  I''ll close it out as a
dup.

eric