Date: Thu, 9 Oct 1997 19:25:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: robin@intercore.com (Robin Cutshaw) Cc: freebsd-current@FreeBSD.ORG, robin@intercore.com Subject: Re: NFS cache problem in 3.0 SNAP Message-ID: <199710091925.MAA07343@usr08.primenet.com> In-Reply-To: <19971009115020.21318@num1sun.intercore.com> from "Robin Cutshaw" at Oct 9, 97 11:50:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I just upgraded to 3.0-971003-SNAP and have an NFS client problem. If > I change a file on the NFS server (FreeBSD 2.2.1), the change does not > show up on the 3.0 client if I had previously read the file before the > change. The change didn't show up for a minute or so. I then unmounted > the directory and remounted it at which point the change showed up. > > This didn't happen with the previous snap (3.0-970209-SNAP). Are you changing metadata, or file contents? If file contents, then you are asking for distributed cache coherency; the amount of time you wait will dictate whether or not the lease has expired and the data will be refetched. NFS assumes that you will use locks to access ranges, and that locked ranges will be flushed from the read cache at lock time. This is actually possible to assert locally in VOP_ADVLOCK, but this will not protect you from two clients in the same page without a veto-based mechanism to guard against coelescing a bad lock in with good locks. As long as you don't rely on the locks, you should be OK. Clearly, the real fix is to assert the lock with a buffer time stamp if it's locally cached data in the lock range, and have seperate status for "range written since this time". To do this naievely, you would use file modification time. If you are using mmap() and expecting a change, use munmap() to throw the pages away and remap them. This will, in effect, cause a cache invalidation locally. You will still have whatever issues you have in terms of guaranteeing non-concurrent write access. You may want to consider MNFS? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710091925.MAA07343>