From: Peter Staubach <staubach@redhat.com>
To: "Lever, Charles" <Charles.Lever@netapp.com>
Cc: Thomas Stockheim <tommi@bub-agema.de>, nfs@lists.sourceforge.net
Subject: Re: NFS problem - close to open cache consistency broken ?
Date: Thu, 15 Sep 2005 10:19:24 -0400 [thread overview]
Message-ID: <432982EC.4070604@redhat.com> (raw)
In-Reply-To: <044B81DE141D7443BCE91E8F44B3C1E288E451@exsvl02.hq.netapp.com>
Lever, Charles wrote:
>
>peter, do you happen to know how the solaris NFS client behaves when an
>application holds a file open like this?
>
>close-to-open is a convention, not a specification, so it's really up to
>the client developers to implement what they think is right. i'm
>guessing that the Linux client is working as designed here. i'm not
>convinced it's very *convenient* behavior, though.
>
The Solaris client issues an over the wire GETATTR for virtually every open
call. The client also flushes data when the last reference to an open file
is closed. This is on a per file descriptor basis and not a system wide
basis. Therefore, even if the file is held open, the close-to-open
semantics
are still maintained, albeit on a per file descriptor level.
The NFS client uses attributes from every call except WRITE responses to do
cache validation. The file being open for reading and/or writing is not
taken into account.
Thanx...
ps
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2005-09-15 14:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-15 13:50 NFS problem - close to open cache consistency broken ? Lever, Charles
2005-09-15 14:19 ` Peter Staubach [this message]
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
[not found] <6063053.1126674084242.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
2005-09-15 7:47 ` Thomas Stockheim
-- strict thread matches above, loose matches on Subject: below --
2005-09-14 2:22 Lever, Charles
2005-09-13 9:04 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=432982EC.4070604@redhat.com \
--to=staubach@redhat.com \
--cc=Charles.Lever@netapp.com \
--cc=nfs@lists.sourceforge.net \
--cc=tommi@bub-agema.de \
/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.