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. Thanks, --matt ps. Sorry for the late notice. On Sat, Feb 25, 2006 at 07:16:58PM -0800, Matthew Ahrens wrote:> Event: putback-to > Parent workspace: /ws/onnv-gate > (elpaso:/ws/onnv-gate) > Child workspace: /home/ahrens/zapbs > (zion.eng:/export/home/ahrens/zapbs) > User: ahrens > > Comment: > 6389368 fat zap should use 16k blocks (with backwards compatability) > > Files: > update: usr/src/uts/common/fs/zfs/dbuf.c > update: usr/src/uts/common/fs/zfs/dmu_tx.c > update: usr/src/uts/common/fs/zfs/dnode.c > update: usr/src/uts/common/fs/zfs/sys/zap_impl.h > update: usr/src/uts/common/fs/zfs/sys/zap_leaf.h > update: usr/src/uts/common/fs/zfs/zap.c > update: usr/src/uts/common/fs/zfs/zap_leaf.c > update: usr/src/uts/common/fs/zfs/zap_micro.c > > Examined files: 8 > > Contents Summary: > 8 update----- End forwarded message -----
Matthew Ahrens wrote:> 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. > >So if we have filesystems made with build 32 (or something <35), old files will still be readable, but new writes to the disk won''t be readable by the older builds. My question is: Is there any benefit to recreating these filesystems under b35 so that all files are written in the new format from the beginning, and there is no data using the compatibility mode? -Kyle> 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. > > Thanks, > --matt > > ps. Sorry for the late notice. > > On Sat, Feb 25, 2006 at 07:16:58PM -0800, Matthew Ahrens wrote: > >> Event: putback-to >> Parent workspace: /ws/onnv-gate >> (elpaso:/ws/onnv-gate) >> Child workspace: /home/ahrens/zapbs >> (zion.eng:/export/home/ahrens/zapbs) >> User: ahrens >> >> Comment: >> 6389368 fat zap should use 16k blocks (with backwards compatability) >> >> Files: >> update: usr/src/uts/common/fs/zfs/dbuf.c >> update: usr/src/uts/common/fs/zfs/dmu_tx.c >> update: usr/src/uts/common/fs/zfs/dnode.c >> update: usr/src/uts/common/fs/zfs/sys/zap_impl.h >> update: usr/src/uts/common/fs/zfs/sys/zap_leaf.h >> update: usr/src/uts/common/fs/zfs/zap.c >> update: usr/src/uts/common/fs/zfs/zap_leaf.c >> update: usr/src/uts/common/fs/zfs/zap_micro.c >> >> Examined files: 8 >> >> Contents Summary: >> 8 update >> > > ----- End forwarded message ----- > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
On Sat, Mar 04, 2006 at 09:45:37AM -0500, Kyle McDonald wrote:> Matthew Ahrens wrote: > >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. > > So if we have filesystems made with build 32 (or something <35), old > files will still be readable, but new writes to the disk won''t be > readable by the older builds.That''s correct.> My question is: Is there any benefit to recreating these filesystems > under b35 so that all files are written in the new format from the > beginning, and there is no data using the compatibility mode?Using filesystems with the old format poses no problem, and they are in no way second-class citizens. The change improves performance of very large directories (eg. with over a million entries). To take advantage of the improvement on existing filesystems, simply re-create any large directories. For example, you could run mkdir bigdir2; mv bigdir1/* bigdir2; rmdir bigdir1 Of course, using shell expansion on a million entries might not work that well, but I''m sure you can figure out how best to accomplish this using xargs(1) or something :-) --matt
On Sat, 4 Mar 2006, Matthew Ahrens wrote:> On Sat, Mar 04, 2006 at 09:45:37AM -0500, Kyle McDonald wrote: > > Matthew Ahrens wrote: > > >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. > > > > So if we have filesystems made with build 32 (or something <35), old > > files will still be readable, but new writes to the disk won''t be > > readable by the older builds. > > That''s correct. > > > My question is: Is there any benefit to recreating these filesystems > > under b35 so that all files are written in the new format from the > > beginning, and there is no data using the compatibility mode? > > Using filesystems with the old format poses no problem, and they are in > no way second-class citizens. The change improves performance of very > large directories (eg. with over a million entries). To take advantage > of the improvement on existing filesystems, simply re-create any large > directories. > > For example, you could run > mkdir bigdir2; mv bigdir1/* bigdir2; rmdir bigdir1 > Of course, using shell expansion on a million entries might > not work that well, but I''m sure you can figure out how best to > accomplish this using xargs(1) or something :-)OK Matt - the upward compatibility of this change is easy to grok. Ques: will this enhancement make it into the release of ZFS that''ll go into (Sol 10) Update 2? BTW: Keep up the awesome work on ZFS! :) Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
On Sat, Mar 04, 2006 at 09:48:47PM -0600, Al Hopper wrote:> > OK Matt - the upward compatibility of this change is easy to grok. > > Ques: will this enhancement make it into the release of ZFS that''ll go into > (Sol 10) Update 2?Yes. Everything ZFS that has gone into build 36 or ealier will be in S10U2, plus some additional fixes beyond that. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On Sat, Mar 04, 2006 at 09:48:47PM -0600, Al Hopper wrote:> Ques: will this enhancement make it into the release of ZFS that''ll go into > (Sol 10) Update 2?Yep, along with a bunch of other huge performance wins (and bug fixes) that were just integrated into Solaris Nevada yesterday.> BTW: Keep up the awesome work on ZFS! :)Thanks, we''ll do our best! --matt