Hi!
I have a questions that may be a FAQ:
An NFS client machine has several processes that open a file on a NFS
server read-only for quite a long time (server processes).
The file gets replaced on the NFS server.
The client processes still have the old copy open.
A new process on the NFS client also only sees the old copy of that
file. Only after the running processes are killed or close() the
filehandle and the filesystems gets remounted the NFS client machine
sees the new version of that file.
Is that expected behaviour? Is there any local NFS client cache timeout
involved?
Greetings
--
Robert Sander
Manager
Information Systems http://www.epigenomics.com Kastanienallee 24
+493024345330 10435 Berlin
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
hi robert-
> An NFS client machine has several processes that open a file on a NFS
> server read-only for quite a long time (server processes).
>=20
> The file gets replaced on the NFS server.
>=20
> The client processes still have the old copy open.
>=20
> A new process on the NFS client also only sees the old copy of that
> file. Only after the running processes are killed or close() the
> filehandle and the filesystems gets remounted the NFS client machine
> sees the new version of that file.
>=20
> Is that expected behaviour? Is there any local NFS client=20
> cache timeout involved?
there are three effects in play here:
1. close-to-open cache coherency
2. weak cache consistency
3. attribute cache timeout
i suspect you are using NFSv2 on an older 2.4 kernel. can you provide
your mount options via "cat /proc/mount" and the output of "uname -a" ?
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 3 Nov 2003 15:36:27 +0000 (UTC),
"Lever, Charles" <[email protected]> wrote:
> there are three effects in play here:
>
> 1. close-to-open cache coherency
> 2. weak cache consistency
> 3. attribute cache timeout
>
> i suspect you are using NFSv2 on an older 2.4 kernel. can you provide
> your mount options via "cat /proc/mount" and the output of "uname -a" ?
Hi!
This happened independently on two NFS-Servers with several clients.
1. NFS-Server: 2.4.20 running kernel-nfsd
Client: 2.4.19-64GB-SMP (SuSE SLES)
/proc/mounts: rw,v3,rsize=4096,wsize=4096,hard,intr,udp,nolock
Client: 2.4.20
rw,v3,rsize=8192,wsize=8192,hard,intr,udp,nolock
2. NFS-Server: 2.4.20 running userspace-nfsd
Client: 2.4.19-64GB-SMP (SuSE SLES)
ro,v2,rsize=4096,wsize=4096,hard,intr,udp,nolock
The second combination obviously runs NFSv2 but we had that effect with
the first combination and NFSv3, too.
Greetings
--
Robert Sander
Manager
Information Systems http://www.epigenomics.com Kastanienallee 24
+493024345330 10435 Berlin
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs