From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: mtk.manpages@gmail.com,
Ganesha NFS List <nfs-ganesha-devel@lists.sourceforge.net>,
lkml <linux-kernel@vger.kernel.org>,
Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
"J. Bruce Fields" <bfields@fieldses.org>,
Neil Brown <neilb@suse.de>,
samba-technical@lists.samba.org,
"Michael Kerrisk (gmail)" <mtk.manpages@gmail.com>
Subject: OFD ("file private") locks and NFS
Date: Tue, 29 Apr 2014 10:38:54 +0200 [thread overview]
Message-ID: <535F651E.6090204@gmail.com> (raw)
Hi Jeff,
I've been looking a bit at the fcntl() documentation of traditional
(F_SETLK) record locking, and a question just jumped out at me. Is
it worth considering some future-proofing in the design of OFD locks
("open file description locks", formerly known as "file-private locks")?
What I am thinking of here is that on some systems, the traditional
'struct flock' has a nonstandard field, l_sysid, that is used on F_GETLK
to identify the remote system on which a lock is held. Should the design
of OFD locks allow for such a field (now, or in the future), which might
be useful in the context of locking on network file systems such as NFS.
Put more simply, should the new OFD locking system be using a new
structure for describing locks, rather than the traditional 'struct
flock'? Defining a new structure, might be useful to allow for
future extensions to the API.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next reply other threads:[~2014-04-29 8:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 8:38 Michael Kerrisk (man-pages) [this message]
2014-04-29 8:47 ` OFD ("file private") locks and NFS Michael Kerrisk (man-pages)
[not found] ` <535F670B.4060704-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-29 11:11 ` Jeff Layton
[not found] ` <20140429071153.176c7404-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2014-04-29 11:15 ` Michael Kerrisk (man-pages)
2014-04-29 11:40 ` Matt W. Benjamin
[not found] ` <1482413734.4.1398771608019.JavaMail.root-DQa+Qhn4Z593Hjf6844flrbbgpPoC6wPvwx5bNz670MAvxtiuMwx3w@public.gmane.org>
2014-04-29 11:50 ` Jeff Layton
[not found] ` <20140429075046.39fc9c3f-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2014-04-29 15:11 ` Frank Filz
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=535F651E.6090204@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=bfields@fieldses.org \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=nfs-ganesha-devel@lists.sourceforge.net \
--cc=samba-technical@lists.samba.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;
as well as URLs for NNTP newsgroup(s).