All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.