All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: NFS <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH - alt-2] NFSv4:  Don't try to recover NFSv4 locks when they are lost.
Date: Thu, 5 Sep 2013 09:48:43 +1000	[thread overview]
Message-ID: <20130905094843.3733515a@notabene.brown> (raw)
In-Reply-To: <1378305066.3527.8.camel@leira.trondhjem.org>

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On Wed, 4 Sep 2013 14:31:07 +0000 "Myklebust, Trond"
<Trond.Myklebust@netapp.com> wrote:

> On Wed, 2013-09-04 at 17:04 +1000, NeilBrown wrote:
> > 
> > When an NFSv4 client loses contact with the server it can lose any
> > locks that it holds.
> > 
> > Currently when it reconnects to the server it simply tries to reclaim
> > those locks.  This might succeed even though some other client has
> > held and released a lock in the mean time.  So the first client might
> > think the file is unchanged, but it isn't.  This isn't good.
> > 
> > If, when recovery happens, the locks cannot be claimed because some
> > other client still holds the lock, then we get a message in the kernel
> > logs, but the client can still write.  So two clients can both think
> > they have a lock and can both write at the same time.  This is equally
> > not good.
> > 
> > There was a patch a while ago
> >   http://comments.gmane.org/gmane.linux.nfs/41917
> > 
> > which tried to address some of this, but it didn't seem to go
> > anywhere.  That patch would also send a signal to the process.  That
> > might be useful but for now this patch just causes writes to fail.
> > 
> > For NFSv4 (unlike v2/v3) there is a strong link between the lock and
> > the write request so we can fairly easily fail any IO of the lock is
> > gone.  While some applications might not expect this, it is still
> > safer than allowing the write to succeed.
> > 
> > Because this is a fairly big change in behaviour a module parameter,
> > "recover_locks", is introduced which defaults to true (the current
> > behaviour) but can be set to "false" to tell the client not to try to
> > recover things that were lost.
> > 
> > Signed-off-by: NeilBrown <neilb@suse.de>
> 
> Thanks!
> 
> > --
> > This alternative uses a module parameter which defaults to the current,
> > incorrect, behaviour.
> > I suspect we don't want that one..
> 
> Agreed. We also need to document the module parameter, so I'm adding a
> little blurb in Documentation/kernel-parameters.txt (see attachment).
> 
> I'd also like to change the parameter name to "recover_lost_locks" to
> make it a little more obvious.
> 
> Finally, I'd like to move the parameter to fs/nfs/super.c so that we can
> use the same modprobe.conf 'options' lines for back ports of this patch
> (yes I strongly suspect we will want to back port this patch to distro
> kernels).
> 
> See attachment.

Looks good - thanks.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

      reply	other threads:[~2013-09-04 23:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-04  7:04 [PATCH - alt-2] NFSv4: Don't try to recover NFSv4 locks when they are lost NeilBrown
2013-09-04 14:31 ` Myklebust, Trond
2013-09-04 23:48   ` NeilBrown [this message]

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=20130905094843.3733515a@notabene.brown \
    --to=neilb@suse.de \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.