public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: jlnance@unity.ncsu.edu
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Jim Nance <jlnance@us54.synopsys.com>,
	jlnance@unity.ncsu.edu, linux-kernel@vger.kernel.org,
	gary.nifong@synopsys.COM, James.Nance@synopsys.COM,
	david.thomas@synopsys.COM
Subject: Re: NFS problems with Linux-2.4
Date: Sun, 18 May 2003 20:53:16 -0400	[thread overview]
Message-ID: <20030519005316.GA20055@ncsu.edu> (raw)
In-Reply-To: <shsznlkjo53.fsf@charged.uio.no>

On Sun, May 18, 2003 at 05:00:24PM +0200, Trond Myklebust wrote:
> 
> Sorry. stat doesn't obey close-to-open. It relies on standard
> attribute caching. close-to-open means "open()" (and only "open()")
> checks data cache consistency...

Trond,
    Thanks for the info.  Here is a section of the man page for open.
Is the information it gives correct wrt using link & stat?

       O_EXCL When  used with O_CREAT, if the file already exists
              it is an error and the open will fail. In this con
              text,  a  symbolic link exists, regardless of where
              its points to.  O_EXCL is broken on NFS  file  sys
              tems,  programs  which  rely  on  it for performing
              locking tasks will contain a race  condition.   The
              solution for performing atomic file locking using a
              lockfile is to create a unique file on the same  fs
              (e.g., incorporating hostname and pid), use link(2)
              to make a link to the lockfile. If  link()  returns
              0,  the lock is successful.  Otherwise, use stat(2)
              on the unique file to check if its link  count  has
              increased to 2, in which case the lock is also suc
              cessful.

Thanks,

Jim

  reply	other threads:[~2003-05-19  0:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-13 14:50 NFS problems with Linux-2.4 jlnance
2003-05-13 15:19 ` Trond Myklebust
2003-05-15 15:22   ` Jim Nance
2003-05-18 15:00     ` Trond Myklebust
2003-05-19  0:53       ` jlnance [this message]
2003-05-19 11:27         ` Trond Myklebust
2003-05-19 20:02       ` Jim Nance
2003-05-13 19:07 ` jjs
2003-05-13 19:24   ` Roland Dreier
2003-05-13 21:55     ` jjs
2003-05-13 23:11   ` Alan Cox
     [not found] <482A3FA0050D21419C269D13989C6113127532@lavender-fe.eng.netapp.com>
2003-05-27 17:29 ` jlnance

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=20030519005316.GA20055@ncsu.edu \
    --to=jlnance@unity.ncsu.edu \
    --cc=James.Nance@synopsys.COM \
    --cc=david.thomas@synopsys.COM \
    --cc=gary.nifong@synopsys.COM \
    --cc=jlnance@us54.synopsys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox