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 over NFSv3 introduces kernel and mountd dependency

Date: Mon, 13 Mar 2006 18:11:37 -0700
From: Robert Thurlow <robert dot thurlow at sun dot com>
To: on-all at eng dot sun dot com, onnv-gate at onnv dot eng dot sun dot com
Subject: Flag Day: .zfs over NFSv3 introduces kernel and mountd dependency

If you use BFU to update your machine, you can safely ignore this
message.

My putback of:

6344186 NFSv3 needs to support .zfs (like NFSv4 already does)

enables the contents of .zfs to be visible via NFSv3. As a result,
the interface that the NFS mount daemon uses to get NFS filehandles
from the kernel has changed, so a new kernel will not work with an
old mountd, and vice versa.  Cap-Eye Install users and people who
copy NFS kernel modules will need to get a new mountd binary if
this fix is present in their kernel and they share any filesystems.
If you forget, mountd will syslog about the mismatch at LOG_DEBUG
level, so it won't be visible by default on the server.  Your NFSv2
and NFSv3 clients will see a failure like this:

# mount -o vers=3 fsh-maguro:/export/home /mnt
nfs mount: fsh-maguro:/export/home: Bad address

NFSv4 service will not be affected by the mismatch.  The fix is to
copy over a new mountd binary and run "svcadm restart nfs/server".

Rob T