From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: Olaf Kirch <okir@suse.de>,
nfsv4@linux-nfs.org, nfs@lists.sourceforge.net
Subject: Re: NFS file locking for clustered filesystems
Date: Tue, 10 Aug 2004 17:43:14 -0700 [thread overview]
Message-ID: <1092184994.5857.19.camel@lade.trondhjem.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0408101139260.11489@localhost.localdomain>
P=E5 ty , 10/08/2004 klokka 17:15, skreiv Sridhar Samudrala:
> I gathered the following from your suggestions to make the cluster filesy=
stem
> process the lock/unlock calls asynchronously,
>=20
> NLM LOCK/UNLOCK Call on a file in a cluster filesystem exported from an N=
FS
> server will always respond with NLM LOCK/UNLOCK Reply with NLM_BLOCKED as=
the
> status.
No. That would break the spec. See:
http://www.opengroup.org/onlinepubs/9629799/NLM_LOCK.htm#tagcjh_11_11
NLM_BLOCKED is only a valid response if the client actually asked for
blocking behaviour.
In the case where the server is not able to reply in a timely fashion (I
would suggest a short timeout period of a few seconds) it should reply
with LCK_DENIED. (Note that when I talk about a "short timeout period",
I do not mean that lockd itself is allowed to block.)
> Once the cluster filesystem is done granting or denying the lock, the ser=
ver
> will send a NLM GRANTED_MSG/GRANTED_RES callbacks with the appropriate st=
atus.
>=20
> Is this correct?
See above. That is only true if the client requested a blocking lock.
> As Olaf suggested, can't we use the existing fl_notify callback instead o=
f
> setting up a new callback?
Possibly. As long as the design remains clean...
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-08-11 0:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-13 21:32 NFS file locking for clustered filesystems Sridhar Samudrala
2004-08-02 10:51 ` Olaf Kirch
2004-08-02 15:38 ` Trond Myklebust
2004-08-11 0:15 ` Sridhar Samudrala
2004-08-11 0:43 ` Trond Myklebust [this message]
2004-08-11 21:35 ` Sridhar Samudrala
2004-08-12 5:34 ` Trond Myklebust
2004-08-17 0:46 ` Sridhar Samudrala
2004-08-17 18:00 ` Trond Myklebust
2004-08-11 18:22 ` force unmount for NFSv3 client Goutham Kurra
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=1092184994.5857.19.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=nfs@lists.sourceforge.net \
--cc=nfsv4@linux-nfs.org \
--cc=okir@suse.de \
--cc=sri@us.ibm.com \
/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.