From: Luis Henriques <luis.henriques@canonical.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Regretion on NFS in mainline kernel
Date: Wed, 18 Apr 2012 18:35:37 +0100 [thread overview]
Message-ID: <20120418173537.GE3979@zeus> (raw)
In-Reply-To: <20120418105147.2a6f1c55@corrin.poochiereds.net>
On Wed, Apr 18, 2012 at 10:51:47AM -0400, Jeff Layton wrote:
> On Wed, 18 Apr 2012 14:41:45 +0000
> "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote:
>
> > Right. Random (and wrong!) changes such as the above won't fix the
> > problem. That code is perfectly correct (look at the nfs4_reclaim_locks
> > error cases to see why).
> >
>
> Ugh, ok I see and that code is correct even if it's a bit hard to
> follow...
>
> We clear the state_flag_bit on the first attempt against that lock so
> if it returns 0 (meaning a successful reclaim, we'll skip over it on
> the next pass through the loop.
>
> > Have you instead looked into what these applications are doing? Are they
> > perhaps opening the file read only, then trying to apply an exclusive
> > BSD lock (something which NFSv4 cannot support)?
> >
> > IOW: does the problem go away if you mount with 'local_lock=flock'?
> >
> I suspect that that is the trigger here. Sadly common among userspace
> apps...
Ok, I'll ask some of the guys reporting the bug to try to use that option
to mount. Is there any other useful information that could be collected
to help sorting this out?
Btw, there was someone reporting that an easy reproducer of this problem
is to just run:
$ /usr/bin/flock /file/on/nfs echo Fish
Cheers,
--
Luis
next prev parent reply other threads:[~2012-04-18 17:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-18 11:26 Regretion on NFS in mainline kernel Luis Henriques
2012-04-18 13:28 ` Jeff Layton
2012-04-18 13:57 ` Luis Henriques
2012-04-18 14:04 ` Myklebust, Trond
2012-04-18 14:13 ` Luis Henriques
2012-04-18 14:15 ` Jeff Layton
2012-04-18 14:41 ` Myklebust, Trond
2012-04-18 14:51 ` Jeff Layton
2012-04-18 17:35 ` Luis Henriques [this message]
2012-04-18 17:36 ` [PATCH 0/2] Fix regression " Trond Myklebust
2012-04-18 17:42 ` Jeff Layton
2012-04-18 17:50 ` Luis Henriques
2012-04-19 9:30 ` Luis Henriques
2012-04-19 13:48 ` Luis Henriques
2012-04-19 17:29 ` Myklebust, Trond
2012-04-19 20:46 ` Luis Henriques
2013-01-04 10:05 ` Mario Bachmann
2013-01-04 14:15 ` Myklebust, Trond
2013-01-06 10:48 ` Mario Bachmann
2012-04-18 17:36 ` [PATCH 1/2] NFSv4: Ensure that the LOCK code sets exception->inode Trond Myklebust
2012-04-18 17:36 ` [PATCH 2/2] NFSv4: Ensure that we check lock exclusive/shared type against open modes Trond Myklebust
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=20120418173537.GE3979@zeus \
--to=luis.henriques@canonical.com \
--cc=Trond.Myklebust@netapp.com \
--cc=jlayton@redhat.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.