From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Jeff Layton'" <jlayton@poochiereds.net>,
"'Trond Myklebust'" <trond.myklebust@primarydata.com>
Cc: "'Benjamin Coddington'" <bcodding@redhat.com>,
"'Anna Schumaker'" <anna.schumaker@netapp.com>,
"'Linux NFS Mailing List'" <linux-nfs@vger.kernel.org>
Subject: RE: [PATCH 0/3] Include OFD lock owners when looking up state
Date: Fri, 1 Apr 2016 13:24:17 -0700 [thread overview]
Message-ID: <02e601d18c54$781aaa50$684ffef0$@mindspring.com> (raw)
In-Reply-To: <20160401121924.70569ef2@synchrony.poochiereds.net>
> > On Fri, Apr 1, 2016 at 11:48 AM, Benjamin Coddington
> > <bcodding@redhat.com> wrote:
> > > On Fri, 1 Apr 2016, Trond Myklebust wrote:
> > >
> > >> On Fri, Apr 1, 2016 at 11:34 AM, Benjamin Coddington
> > >> <bcodding@redhat.com> wrote:
> > >> > The client sends IO only under the open stateid when using OFD
> > >> > (and flock) locking instead of the appropriate lock stateid
> > >> > because the nfs_lock_context only tracks POSIX lockowners, which
> > >> > is the reference to the process' file table.
> > >> >
> > >> > This is a problem for two reasons. The first is that rfc7530,
> > >> > section-9.1.4.5 states that IO sent by an entity corresponding to
> > >> > the lock-owner which holds a byte-range lock should be sent under
> > >> > the lock stateid for that lock. Otherwise, a server enforcing
> > >> > mandatory byte-range locking might reject that operation.
> > >> > Secondly, not tracking OFD lock owners means that accounting for
> > >> > IO sent under those owners is broken. That creates a problem for
> > >> > some work to guarantee an unlock will be sent after operations
> scheduled under a lock complete.
> > >>
> > >> OK. Can we just kill this in the bud? No support for OFD locks in
NFS:
> > >> this is nuts....
> > >
> > > Will you explain why it is nuts? That would be helpful for me.
> >
> > The point of the OFD crap was that they should work exactly like POSIX
> > locks except for the unlock-on-close, the latter being managed by the
> > VFS layer. If we have to make loads of changes to NFS in order to
> > change the tracking of lock owners, then the design itself is broken,
> > and needs to be fixed.
>
>
> No, there were other reasons for them as well.
>
> For instance, traditional POSIX locks are useless for serializing betwee
> threads within the same process because the lock owner is always the same
> regardless of which thread you're using. With OFD locks, this is possible
if
> each thread has its own file description.
Which is a feature humongously useful for Ganesha... Not that Ganesha will
ever use OFD locks over NFS...
I have used OFD locks over NFS to make sure that Ganesha handles one
open-owner to many lock-owners correctly.
Of course it may be a real question if anyone other than Ganesha (and maybe
Samba) will ever use OFD locks since they aren't a POSIX standard...
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
next prev parent reply other threads:[~2016-04-01 20:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 15:34 [PATCH 0/3] Include OFD lock owners when looking up state Benjamin Coddington
2016-04-01 15:34 ` [PATCH 1/3] NFS: add get_nfs_lock_context, find_nfs_lock_context Benjamin Coddington
2016-04-01 16:45 ` kbuild test robot
2016-04-01 17:03 ` kbuild test robot
2016-04-01 15:34 ` [PATCH 2/3] NFS: add OFD lock owners to nfs_lock_context Benjamin Coddington
2016-04-01 16:17 ` kbuild test robot
2016-04-01 16:55 ` kbuild test robot
2016-04-01 15:34 ` [PATCH 3/3] NFSv4: use OFD lock owners in lock state lookup Benjamin Coddington
2016-04-01 15:47 ` [PATCH 0/3] Include OFD lock owners when looking up state Trond Myklebust
2016-04-01 15:48 ` Benjamin Coddington
2016-04-01 16:09 ` Trond Myklebust
2016-04-01 16:19 ` Jeff Layton
2016-04-01 20:24 ` Frank Filz [this message]
2016-04-01 16:35 ` Benjamin Coddington
2016-04-01 16:09 ` Jeff Layton
2016-04-01 17:17 ` Benjamin Coddington
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='02e601d18c54$781aaa50$684ffef0$@mindspring.com' \
--to=ffilzlnx@mindspring.com \
--cc=anna.schumaker@netapp.com \
--cc=bcodding@redhat.com \
--cc=jlayton@poochiereds.net \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox