Re: [zfs-discuss] zpool import: snv_33 to S10 6/06
Hi, [EMAIL PROTECTED] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool import: snv_33 to S10 6/06
On Wed, Aug 23, 2006 at 09:57:04AM -0400, James Foronda wrote: Hi, [EMAIL PROTECTED] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool import: snv_33 to S10 6/06
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool import: snv_33 to S10 6/06
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
