eric kustarz <[EMAIL PROTECTED]> 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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
