On 12/5/09 7:25 PM, "Ricardo Labiaga" <ricardo.labiaga@xxxxxxxxxx> wrote:
> These patches due improve the situation. I still see a number of sequence
^^^
do
(apologies for the spam, but better be clear...)
- ricardo
> calls with sessionID=0 and the same sequenceID that triggered the initial
> BADSESSION. It does recover after the session is fully established though.
>
> The sequenceID's with sessionID=0 are generated because nfs4_reset_session()
> clears the DRAINING flag and wakes the pending RPCs even on error. This is
> broken, since we don't have a valid sessionID. Since we're already in the
> state manager, why not just let the state manager retry if the error is
> recoverable (such as STALE_CLIENTID)?
>
> I'll give that a try after dinner :-)
>
> - ricardo
>
>
>
> On 12/5/09 4:34 PM, "Trond Myklebust" <Trond.Myklebust@xxxxxxxxxx> wrote:
>
>> On Sat, 2009-12-05 at 13:42 -0800, Labiaga, Ricardo wrote:
>>>
>>>
>>> On 12/5/09 1:39 PM, "Ricardo Labiaga" <ricardo.labiaga@xxxxxxxxxx> wrote:
>>>
>>>> On 12/5/09 1:12 PM, "Trond Myklebust" <Trond.Myklebust@xxxxxxxxxx> wrote:
>>>>
>>>>> On Sat, 2009-12-05 at 12:55 -0800, Labiaga, Ricardo wrote:
>>>>>> Tried with this patch but it didn't make a difference.
>>>>>
>>>>> You are still seeing RPC calls with 0 session ids?
>>>>>
>>>>
>>>> Yes, right after the session is destroyed, and before it's recreated. The
>>>> original RPC that got the BAD_SESSION error keeps on trying.
>>>>
>>>
>>> I should clarify. It's not a retransmission, the client issues the same
>>> compound with a new XID.
>>>
>>> - ricardo
>>>
>>>> After the session is recreated, the same RPC is issued (with the same
>>>> sequenceID) but with the new sessionID. This time it fails with
>>>> SEQ_MISORDERED. This repeats indefinitely until the process is manually
>>>> interrupted.
>>>>
>>>>>> I haven't tried applying the second cleanup patch yet since it
>>>>>> didn't apply cleanly on top of nfs-for-next. Is this the branch you
>>>>>> used?
>>>>>
>>>>> I've pushed out all patches (including the cleanup patch) onto
>>>>> nfs-for-next now...
>>>>>
>>>>
>>>> Got it, I was able to apply both patches. The results above are with both
>>>> patches.
>>
>> I've found some other interesting session reset cases. I've coded up
>> some fixes, and pushed them to the nfs-for-next tree.
>>
>> In particular, please see
>>
>>
http://git.linux-nfs.org/?p=trondmy/nfs-2.6.git&a=commitdiff&h=f26468fb9384e7>>
3
>> fb357d2e84d3e9c88c7d1129d
>> which should ensure that we always reinitialise the slot sequence number
>> after a server reboot.
>>
>> Could you please see if that in any way changes the above behaviour?
>>
>> Cheers
>> Trond
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
