From nobody  Mon Oct  6 17:06:29 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA09612;
          Mon, 6 Oct 1997 17:06:29 -0700 (PDT)
          (envelope-from nobody)
Message-Id: <199710070006.RAA09612@hub.freebsd.org>
Date: Mon, 6 Oct 1997 17:06:29 -0700 (PDT)
From: mika@cs.caltech.edu
To: freebsd-gnats-submit@freebsd.org
Subject: NFS inconsistencies resulting from changes to filesystem mouted read-only
X-Send-Pr-Version: www-1.0

>Number:         4713
>Category:       kern
>Synopsis:       NFS inconsistencies resulting from changes to filesystem mouted read-only
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    peter
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct  6 17:10:01 PDT 1997
>Closed-Date:    Mon May 11 01:54:53 PDT 1998
>Last-Modified:  Mon May 11 02:03:41 PDT 1998
>Originator:     Mika Nystrom
>Release:        FreeBSD-CURRENT/SMP 3.0
>Organization:
Dept. of C.S., California Institute of Technology
>Environment:
FreeBSD s1.cs.caltech.edu 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Wed Oct  1 20:23:54 PDT 1997     mika@obelix.cs.caltech.edu:/usr/src/sys/compile/P6CLIENT_2CPU_128MB  i386

The system is a dual PPro-200 running an SMP kernel.
(Same for the server machine)

>Description:
Changing files on a disk that is remote-mounted 
read-only does not propagate to the clients.

Example: on the server, the file "blah" contains the string
asdfasfd

Executing the following on the server:
# mv blah bleh ; touch blah
# 

gives the result on the client:

(106)s1:/usr/local>cat blah
asdfasfd
(107)s1:/usr/local>cat bleh
asdfasfd

syncing the server does not help

Both cats do lead to NFS traffic between the two hosts (as evidenced by
tcpdump)---strangely enough, rebooting the client does seem to fix
the problem so it doesn't look like a server-side thing.

On the server:

# mount
/dev/sd0a on / (NFS exported, local)
/dev/sd0g on /usr (NFS exported, local)
/dev/sd0e on /var (local)
/dev/sd0f on /var/tmp (local)
procfs on /proc (local)
kernfs on /kern (local)
amd:125 on /ufs
vlsi:/alains on /tmp_mnt/vlsi/alains
mercury:/students on /tmp_mnt/mercury/students (nosuid)
mars:/alains2 on /tmp_mnt/mars/alains2
maestro:/students3 on /tmp_mnt/maestro/students3 (nosuid)


On the client:
(116)s1:/usr/local>mount
/dev/sd0a on / (local)
/dev/sd0e on /var (local)
/dev/sd0f on /var/tmp (NFS exported, local)
procfs on /proc (local)
kernfs on /kern (local)
mfs:22 on /tmp (asynchronous, local)
obelix:/usr on /usr (read-only)
amd:127 on /ufs
mercury:/students on /tmp_mnt/mercury/students (nosuid)
vlsi:/var/spool/mail on /tmp_mnt/vlsi/var/spool/mail (nosuid)
mars:/alains2 on /tmp_mnt/mars/alains2
mars:/alains3 on /tmp_mnt/mars/alains3
maestro:/students3 on /tmp_mnt/maestro/students3 (nosuid)
(117)s1:/usr/local>

The changes propagate after a while---NOT the allowed 30(?) seconds but
sometimes minutes, sometimes hours, or days... some files don't seem
to propagate at all.  The inode numbers do not propagate either.

>How-To-Repeat:
It seems almost (?) deterministic.
>Fix:
Unknown----I don't know that much about NFS.
>Release-Note:
>Audit-Trail:

From: Mika <mika@cs.caltech.edu>
To: freebsd-gnats-submit@freebsd.org, mika@cs.caltech.edu
Cc:  Subject: Re: kern/4713: NFS inconsistencies resulting from changes to filesystem mouted read-only
Date: Mon, 06 Oct 1997 18:20:40 -0700

 We noticed another bug w.r.t. NFS:
 re-installing binaries in /usr causes "state file handle" errors
 (deterministically) the next time those binaries are accessed on
 client systems.  I think it is likely that this is the same bug
 as the one mentioned in kern/4713.
Responsible-Changed-From-To: freebsd-bugs->dfr 
Responsible-Changed-By: joerg 
Responsible-Changed-When: Sun Oct 19 21:07:46 MEST 1997 
Responsible-Changed-Why:  
Doug is Mr. NFS. 

From: Mika Nystrom <mika@cs.caltech.edu>
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: Re: kern/4713 NFS inconsistencies resulting from changes to filesystem mouted read-only 
Date: Wed, 01 Apr 1998 03:43:39 -0800

 This problem disappeared ages ago, but I've been running 3.0-current
 all along (this should have been part of the PR).
 
    Mika
 
 Studded writes:
 >Greetings, :)
 >
 >	I am writing to you in regards to your FreeBSD Problem
 >Report. The FreeBSD project is currently conducting a beta test on
 >version 2.2.6 and feedback as to whether you are still experiencing
 >your problem would be very valuable. 
 >
 >	If you are still experiencing the problem you reported, it
 >would help the project track the problem if you could upgrade to the
 >latest snapshot of 3.0-Current (located at releng22.freebsd.org) and
 >test your problem again. 
 >
 >	If you have any feedback regarding this Problem Report,
 >whether you are still experiencing the problem or whether the PR can
 >be closed, please mail your response to
 >freebsd-gnats-submit@freebsd.org. Please do not respond directly to
 >me. I am merely a humble volunteer and have no official connection to
 >the FreeBSD project. Therefore I cannot make any changes to the status
 >of your Problem Report. It is also very important that you include 
 >the category and number of your Problem Report (kern/4713)
 >in the subject line of your response.
 >
 >	Another option if you need a refresher on the details of your
 >problem or would like to submit a followup is to use the web page
 >interface and look up your PR by number.
 >http://www.freebsd.org/cgi/query-pr-summary.cgi
 >
 >	Thank you for helping to make this the greatest release of
 >FreeBSD ever.
 >
 >Doug
 >
 >
 >-- 
 >***         Chief Operations Officer, DALnet IRC network       ***
 >*** Proud operator, designer and maintainer of the world's largest
 >*** Internet Relay Chat server.  5,328 clients and still growing.
 >*** Try spider.dal.net on ports 6662-4    (Powered by FreeBSD)
 >
Responsible-Changed-From-To: dfr->peter 
Responsible-Changed-By: peter 
Responsible-Changed-When: Sat Apr 25 22:47:48 PDT 1998 
Responsible-Changed-Why:  
I'll revisit this one.. 
State-Changed-From-To: open->closed 
State-Changed-By: peter 
State-Changed-When: Mon May 11 01:54:53 PDT 1998 
State-Changed-Why:  
This has indeed been fixed (as reported), although a search of changes 
does not reveal where it was done. :-/ (easily :-) 
>Unformatted:
