From owner-freebsd-hackers Mon Feb 26 14:26:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B6C9E37B491 for ; Mon, 26 Feb 2001 14:26:45 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QMQBJ44997; Mon, 26 Feb 2001 14:26:11 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 14:26:11 -0800 (PST) From: Matt Dillon Message-Id: <200102262226.f1QMQBJ44997@earth.backplane.com> To: Nate Williams Cc: Marc W , , Drew Eckhardt , freebsd-hackers@FreeBSD.ORG Subject: Re: Is mkdir guaranteed to be 'atomic' ?? References: <200102262202.OAA39275@akira.lanfear.com> <15002.54073.668155.728179@nomad.yogotech.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (owner-freebsd-hackers removed from list) :You're implying that you are making two calls to create the same :directory. Am I correct? : :The answer is 'maybe'? Depends on the remote NFS server. Matt or one :of the other NFS gurus may know more, but I wouldn't count on *anything* :over NFS. If you need atomicity, you need lockd, which isn't :implemented on FreeBSD. : :Nate There are a couple of issues here. First, I'm fairly sure that the NFS server side implementation of mkdir() does *not* guarentee that the operation will be synced to permanent storage on the server side before returning. So if the NFS server crashes and reboots, the just-created directory could disappear. Second, in regards to several clients trying to mkdir() at the same time: mkdir() does not use the same semantics as an O_EXCL file create. This means that *normally* only one of the two clients will succeed in the mkdir() call. However, under certain circumstances (e.g. a server reboot or possibly packet loss / NFS retry) it is possible for the directory to be created yet for *both* client's mkdir() calls to *FAIL* (server reboot), or for *both* client's mkdir() calls to succeed (if one or both clients had packet loss and had to retry the request). Under NFSv3, the only thing that truely guarentees proper operation in regards to competing clients is an O_EXCL file open(). An O_EXCL file open() is guarenteed to succeed on precisely one client when multiple clients are trying to create the same file, and NFSv3 O_EXCL semantics guarentees that NFS retries and server reboots will still result in proper operation (the client doing the retry or the client that succeeded in the open() call will still see a 'success' even if the server reboots or if an NFS retry occurs). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message