From: Benny Halevy <bhalevy@panasas.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Jim Rees <rees@umich.edu>, NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [pnfs] nfs41_sequence_done
Date: Mon, 12 Jul 2010 22:16:45 +0300 [thread overview]
Message-ID: <4C3B6A1D.40202@panasas.com> (raw)
In-Reply-To: <1278962046.12559.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On Jul. 12, 2010, 22:14 +0300, Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> On Mon, 2010-07-12 at 21:58 +0300, Benny Halevy wrote:
>> [pnfs@linux-nfs.org -> linux-nfs@vger.kernel.org]
>>
>> On Jul. 12, 2010, 21:29 +0300, Jim Rees <rees@umich.edu> wrote:
>>> Does anyone still care about this?
>>>
>>> WARNING: nfs41_sequence_done: Operation in progress slot=1 seq=7 highest_used_slotid=1: please report to pnfs@linux-nfs.org if you saw this message
>>
>> Heh, need to update hard-coded instructions to point to the new list...
>>
>>>
>>> I'm getting this on the client side of a pnfs block layout mount against the
>>> spnfs server. Kernel is benny's pnfs-all-2.6.35-rc3-2010-07-01 plus EMC
>>> complex block layout patches. It's possible the complex layout code is to
>>> blame, but I doubt it because this isn't a complex layout mount. I can
>>> provide more details.
>>
>> I agree. This is a generic issue.
>> The patch that adds this check is
>> d6ce9ad DEVONLY: nfs41: Do not free slot if retried while operation was in progress
>>
>> It was originally rejected (http://www.spinics.net/lists/linux-nfs/msg09562.html)
>> due to noise regarding where nfs41_sequence_free_slot is called
>> but that masked the real issue.
>>
>> Can you readily reproduce this?
>> Can you debug also the server side to see if indeed the client retries the RPC
>> while it is in progress on the server?
>
> So what is the root cause here? Is it the known issue that we don't deal
> correctly with an NFS4ERR_DELAY on the SEQUENCE operation?
Yes.
>
> Trond
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-07-12 19:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100712182927.GB22461@merit.edu>
[not found] ` <20100712182927.GB22461-8f4Pc2RrbJmHXe+LvDLADg@public.gmane.org>
2010-07-12 18:58 ` [pnfs] nfs41_sequence_done Benny Halevy
2010-07-12 19:14 ` Trond Myklebust
[not found] ` <1278962046.12559.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2010-07-12 19:16 ` Benny Halevy [this message]
2010-07-12 19:26 ` Trond Myklebust
[not found] ` <1278962763.12559.10.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2010-07-12 19:49 ` [PATCH] nfs41: Do not free slot if retried while operation was in progress Benny Halevy
2010-07-12 19:59 ` 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=4C3B6A1D.40202@panasas.com \
--to=bhalevy@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=rees@umich.edu \
/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.