OpenSolaris

1. Community: OS/Net (ON)
   1. Blogs
   2. Development Process
   3. Developer's Reference
      1. Introduction
      2. Prerequisites
      3. The Source Tree, part 1
      4. The Source Tree, part 2
      5. Building OpenSolaris
      6. Installing and Testing OpenSolaris
      7. Integration Procedure
      8. Best Practices and Requirements
      9. Glossary
   4. Discussions
   5. Installation (from source) Quickstart
      1. Annotated nightly(1) Mail Example
   6. Currently Known Issues
   7. CRT
      1. Advocates & Sponsors
      2. Becoming a CRT Advocate
      3. Charter
      4. RTI nits to avoid
      5. Sponsor Tasks
      6. Becoming a Sponsor
   8. Schedule
   9. ONNV Flag Days, Heads Ups, and Project Integration History
      1. All
      2. Builds 91-95
      3. Builds 86-90
      4. Builds 81-85
      5. Builds 76-80
      6. Builds 71-75
      7. Builds 66-70
      8. Builds 61-65
      9. Builds 56-60
      10. Builds 51-55
      11. Builds 46-50
      12. Builds 41-45
      13. Builds 36-40
      14. Builds 31-35
      15. Builds 26-30
      16. Builds 21-25
   10. Leaders
   11. Observers
   12. Putback Logs
   13. Developing Solaris
       1. Quality Death Spiral
   14. wx
   15. findunref and unreferenced files
   16. Bourne/Korn Shell Coding Conventions

flag day: ZFS on-disk format change

Date: Fri, 3 Mar 2006 15:43:50 -0800
From: Matthew Ahrens <ahrens at sun dot com>
To: on-all at sun dot com, onnv-gate at onnv dot sfbay dot sun dot com, zfs dash discuss at opensolaris dot org
Subject: flag day: ZFS on-disk format change

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 -----