From: Thomas Stockheim <tommi@bub-agema.de>
To: nfs@lists.sourceforge.net
Subject: NFS problem - close to open cache consistency broken ?
Date: Tue, 13 Sep 2005 11:04:41 +0200 [thread overview]
Message-ID: <43269629.3030503@bub-agema.de> (raw)
I'm having a problem with NFS caching after updating from Redhat 8 to
Fedora. Sometimes changes to files ( even when done on the server) just
do not show up. At first we suspected timing problems, but all machines
are synchronized with ntp.
Then I found out how to reproduce it:
1 server: echo xxxx > testfile
2 client: Application 1 on client opens testfile, does nothing with it -
keeps it open forever ( simple fortran program with an open and an
endless loop )
3 client: cat testfile gives xxxx
4 server: echo yyyy > testfile
5 client: cat testfile still shows xxxx
Its not a file attribute caching problem I think, ls -l shows the
correct, updated modificiation time for the file. But the file contents
never get updated. Once I kill the application that was holding open the
testfile, it still shows the wrong content, but any new changes show
immediately.
At first, we tested this on kernel 2.6.11 and 2.6.9. Here, increasing
file size by 1 worked to get the updated file contents on the client,
but decreasing file size did not work.
6a server: echo zzzzz > testfile
7a client: cat testfile shows zzzzz
6b server: echo zzz > testfile
7b server: cat testfile shows xxxx
With kernel 2.6.13, any file size changes show the new content directly,
but if the file size stays constant it still does not work.
I tried all the mount options, but even turning attribute
caching totally off does not seem to help. Mouting as nfsv2 did not help
either.
I assume its a problem of the client, not the server - mounting the
same exports on old redhat 7 with kernel 2.4.2 everything works.
If I understand Close-to-open cache consistency right, having the file
opened from a different application on the same client should not be a
problem ?
Thanks, Thomas
--
************************************************************************
**
** B&B-AGEMA GmbH
**
** Thomas Stockheim
** Juelicher Strasse 338
** D-52070 Aachen
** Germany
**
** Tel. (Zentrale): ++49-(0)241-56878-0
** Tel. (Durchwahl): ++49-(0)241-56878-31
** Fax.: ++49-(0)241-56878-79
** e-mail: <tommi@bub-agema.de>
** Internet: http://www.bub-agema.de
**
************************************************************************
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next reply other threads:[~2005-09-13 9:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-13 9:04 Thomas Stockheim [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-09-14 2:22 NFS problem - close to open cache consistency broken ? Lever, Charles
[not found] <6063053.1126674084242.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
2005-09-15 7:47 ` Thomas Stockheim
2005-09-15 13:50 Lever, Charles
2005-09-15 14:19 ` Peter Staubach
2005-09-15 15:08 ` J. Bruce Fields
2005-09-15 15:12 ` Peter Staubach
[not found] <12528729.1126796454117.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
2005-09-15 15:14 ` Thomas Stockheim
[not found] ` <18266122.1126803664464.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
2005-09-16 7:22 ` Thomas Stockheim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43269629.3030503@bub-agema.de \
--to=tommi@bub-agema.de \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.