zfs discuss - Aug 2006 - zpool import: snv_33 to S10 6/06

Hi,

root at u20# cat /etc/release
                            Solaris Nevada snv_33 X86
           Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 06 February 2006

I have zfs running well on this box.  Now, I want to upgrade to Solaris 
10 6/06 release. 

Question: Will the 6/06 release recognize the zfs created by snv_33?  I 
seem to recall something about being at a certain release level for 6/06 
to be able to import without problems.. I searched the archives but I 
can''t find where I read that anymore.

TIA,

James

On Wed, Aug 23, 2006 at 09:57:04AM -0400, James Foronda
wrote:
> Hi,
> 
> root at u20# cat /etc/release
>                            Solaris Nevada snv_33 X86
>           Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
>                        Use is subject to license terms.
>                           Assembled 06 February 2006
> 
> I have zfs running well on this box.  Now, I want to upgrade to Solaris 
> 10 6/06 release. 
> 
> Question: Will the 6/06 release recognize the zfs created by snv_33?  I 
> seem to recall something about being at a certain release level for 6/06 
> to be able to import without problems.. I searched the archives but I 
> can''t find where I read that anymore.
Yes, new releases of Solaris can seamlessly access any ZFS pools created
with Solaris Nevada or 10 (but not pools from before ZFS was integrated
into Solaris, in October 2005).

However, once you upgrade to build 35 or later (including S10 6/06), do
not downgrade back to build 34 or earlier, per the following message:

	Summary: If you use ZFS, do not downgrade from build 35 or later to
	build 34 or earlier.

	This putback (into Solaris Nevada build 35) introduced a backwards-
	compatable change to the ZFS on-disk format.  Old pools will be
	seamlessly accessed by the new code; you do not need to do anything
	special.

	However, do *not* downgrade from build 35 or later to build 34 or
	earlier.  If you do so, some of your data may be inaccessible with the
	old code, and attemts to access this data will result in an assertion
	failure in zap.c.

	We have fixed the version-checking code so that if a similar change
	needs to be made in the future, the old code will fail gracefully with
	an informative error message.

After upgrading, you should consider running ''zpool upgrade''
to enable
the latest features of ZFS, including ditto blocks, hot spares, and
double-parity RAID-Z.

--matt

On 24/08/2006, at 6:40 AM, Matthew Ahrens wrote:
> However, once you upgrade to build 35 or later (including S10  
> 6/06), do
> not downgrade back to build 34 or earlier, per the following message:
>
> 	Summary: If you use ZFS, do not downgrade from build 35 or later to
> 	build 34 or earlier.
>
> 	This putback (into Solaris Nevada build 35) introduced a backwards-
> 	compatable change to the ZFS on-disk format.  Old pools will be
> 	seamlessly accessed by the new code; you do not need to do anything
> 	special.
>
> 	However, do *not* downgrade from build 35 or later to build 34 or
> 	earlier.  If you do so, some of your data may be inaccessible with  
> the
> 	old code, and attemts to access this data will result in an assertion
> 	failure in zap.c.
This reminds me of something that I meant to ask when this came up  
the first time.

Isn''t the whole point of the zpool upgrade process to allow users to  
decide when they want to remove the "fall back to old version" option?

In other words shouldn''t any change that eliminates going back to an  
old rev require an explicit zpool upgrade?

Boyd

On Thu, Aug 24, 2006 at 08:12:34AM +1000, Boyd Adamson
wrote:
> Isn''t the whole point of the zpool upgrade process to allow users
to
> decide when they want to remove the "fall back to old version"
option?
> 
> In other words shouldn''t any change that eliminates going back to
an
> old rev require an explicit zpool upgrade?
Yes, that is exactly the case.

Unfortunately, builds prior to 35 had some latent bugs which made
implementation of ''zpool upgrade'' nontrivial.  Thus we issued
this
one-time "do not downgrade" message and promptly implemented
''zpool
upgrade''.

--matt

On 24/08/2006, at 8:20 AM, Matthew Ahrens wrote:
> On Thu, Aug 24, 2006 at 08:12:34AM +1000, Boyd Adamson wrote:
>> Isn''t the whole point of the zpool upgrade process to allow
users to
>> decide when they want to remove the "fall back to old
version"
>> option?
>>
>> In other words shouldn''t any change that eliminates going back
to an
>> old rev require an explicit zpool upgrade?
>
> Yes, that is exactly the case.
>
> Unfortunately, builds prior to 35 had some latent bugs which made
> implementation of ''zpool upgrade'' nontrivial.  Thus we
issued this
> one-time "do not downgrade" message and promptly implemented
''zpool
> upgrade''.
Ah. Thanks. It was the one-time nature of this change that I wasn''t  
sure about.

>Hi,
>
>root at u20# cat /etc/release
>                            Solaris Nevada snv_33 X86
>           Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
>                        Use is subject to license terms.
>                           Assembled 06 February 2006
>
>I have zfs running well on this box.  Now, I want to upgrade to Solaris 
>10 6/06 release. 
Aside from mentioned ZFS issues note that "upgrade" is not the proper
word to use here; it''s a "sidegrade" of sorts and it requires
a reinstall
of the OS.

Casper