Hi all,
Has anyone encounter the problem like this?
1. If a user replace a file (which on the Filer) using cp command using Solaris 8 machine such as;
# cp newfile oldfile
2. Then, on Linux server(NFS Client) A , reading the file, the file is new one.
3. But on another Linux server B, reading same file above, the file is stil OLD.
We experienced many times on many files and Linux servers. I suspect some linux cache behavior (attribute caching?), but This situation still remain after a few days...
[Our mount options] rw,nosuid,bg,soft,rsize=8192,wsize=8192,timeo=11,retrans=5
[Our Linux (all)] kernel 2.4.20, based on RHL 7.3
[Filer] F825, NetApp Release 6.3.3D2
I've read Technical report written by Chuck Lever(TR3183), noct and/or noac options may help, but I don't know why such long time Linux does not see a new file.
Anyone? Thanks,
--
Jun Ohata ohhata@tnes.nec.co.jp
Hi all,
Has anyone encounter the problem like this?
If a user replace a file (which on the Filer) using cp command using Solaris 8 machine such as;
# cp newfile oldfile
Then, on Linux server(NFS Client) A , reading the file, the file is new one.
But on another Linux server B, reading same file above,
the file is stil OLD.
We experienced many times on many files and Linux servers. I suspect some linux cache behavior (attribute caching?), but This situation still remain after a few days...
[Our mount options] rw,nosuid,bg,soft,rsize=8192,wsize=8192,timeo=11,retrans=5
[Our Linux (all)] kernel 2.4.20, based on RHL 7.3
[Filer] F825, NetApp Release 6.3.3D2
I've read Technical report written by Chuck Lever(TR3183), noct and/or noac options may help, but I don't know why such long time Linux does not see a new file.
Just a guess here, but are you using ntp to sync the date/time on the filer and the Linux box? I imagine that if there is a big discrepancy, then the Linux box might not know when a cached file needs to be refreshed.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
Comments below.
--On 26 March 2004 07:46 -0500 Steve Losen scl@sasha.acc.virginia.edu wrote:
[Our mount options] rw,nosuid,bg,soft,rsize=8192,wsize=8192,timeo=11,retrans=5
I don't know whether it'll help with your particular problem (on the face of it no reason that it should, in fact) but 'soft' is not an option I'd ever recommend using. Is there some particular reason why 'hard,intr' or just 'hard' is unsuitable for your mounts? Remember, silent data corruption is not your friend, unless you're Enron.
I'd try the 'noac' option, but do anticipate the filer seeing an increase in small attribute lookups from the clients that you do that on.
[Our Linux (all)] kernel 2.4.20, based on RHL 7.3
[Filer] F825, NetApp Release 6.3.3D2
Yes, Filer and Clients using NTP, syncronized correctly..
Hi all,
Has anyone encounter the problem like this?
If a user replace a file (which on the Filer) using cp command using Solaris 8 machine such as;
# cp newfile oldfile
Then, on Linux server(NFS Client) A , reading the file, the file is new one.
But on another Linux server B, reading same file above,
the file is stil OLD.
We experienced many times on many files and Linux servers. I suspect some linux cache behavior (attribute caching?), but This situation still remain after a few days...
[Our mount options] rw,nosuid,bg,soft,rsize=8192,wsize=8192,timeo=11,retrans=5
[Our Linux (all)] kernel 2.4.20, based on RHL 7.3
[Filer] F825, NetApp Release 6.3.3D2
I've read Technical report written by Chuck Lever(TR3183), noct and/or noac options may help, but I don't know why such long time Linux does not see a new file.
Just a guess here, but are you using ntp to sync the date/time on the filer and the Linux box? I imagine that if there is a big discrepancy, then the Linux box might not know when a cached file needs to be refreshed.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
---
Jun Ohata ohhata@tnes.nec.co.jp
On Fri, Mar 26, 2004 at 07:03:54PM +0900, Jun Ohata wrote: :Has anyone encounter the problem like this? : :1. If a user replace a file (which on the Filer) : using cp command using Solaris 8 machine such as; : : # cp newfile oldfile : :2. Then, on Linux server(NFS Client) A , reading the file, the : file is new one. : :3. But on another Linux server B, reading same file above, : the file is stil OLD. : :We experienced many times on many files and Linux servers. :I suspect some linux cache behavior (attribute caching?), :but This situation still remain after a few days...
We experienced this when we went from RH 7.3 (kernel 2.4.18) to RHEL 3 (kernel 2.4.21). After testing several of the NFS client options, we settled on adding nfsvers=2, which completely solved the files not being seen as updated on the clients. Version 2 has other implications (file size less that 2G, no readdir+, etc.), but those were less of an issue than the failure to notice an update of the file.
:[Our mount options] : :rw,nosuid,bg,soft,rsize=8192,wsize=8192,timeo=11,retrans=5
rw,nfsvers=2,rsize=8192,wsize=8192
:[Our Linux (all)] :kernel 2.4.20, based on RHL 7.3
kernel 2.4.21, based on RHEL 3
:[Filer] :F825, NetApp Release 6.3.3D2
F960, NetApp Release 6.3.2
:I've read Technical report written by Chuck Lever(TR3183), :noct and/or noac options may help, but I don't know why :such long time Linux does not see a new file.
We initially suspect caching and so played around with various NFS client cache settings. However, it does appear to be a real bug that needs fixing. We have a RedHat bugzilla entry open on this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113636
==Pythagoras Watson, LLNL ASC Systems Admin., py@llnl.gov, +1.925.424.3620
-
Jun Ohata -
Mark Simmons -
Pythagoras Watson -
Steve Losen