Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-we0-f174.google.com ([74.125.82.174]:33713 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753205Ab2ITRxp (ORCPT ); Thu, 20 Sep 2012 13:53:45 -0400 Received: by weyx8 with SMTP id x8so1453740wey.19 for ; Thu, 20 Sep 2012 10:53:44 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20120920161716.GB4521@fieldses.org> Date: Thu, 20 Sep 2012 13:53:44 -0400 Message-ID: Subject: Re: unhandled error -10026 From: Andy Adamson To: "J. Bruce Fields" Cc: William Dauchy , Linux NFS mailing list , R.Eggermont@tudelft.nl Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Thu, Sep 20, 2012 at 1:47 PM, Andy Adamson wrote: > On Thu, Sep 20, 2012 at 12:17 PM, J. Bruce Fields wrote: >> On Thu, Sep 20, 2012 at 12:06:48PM -0400, Andy Adamson wrote: >>> On Thu, Sep 20, 2012 at 10:34 AM, William Dauchy wrote: >>> > On Tue, Sep 18, 2012 at 11:49 AM, William Dauchy wrote: >>> >> I'm getting a trace following an unhandled error on a linux nfs client >>> >> 3.4.7 x86_64. >>> >> NFS: nfs4_reclaim_open_state: unhandled error -10026. Zeroing state >>> > >>> > For the moment I don't know if the error is coming from a bad server >>> > implementation or if it's on client side. Should I assume that this an >>> > error that should never hit the client? >>> >>> Yes. >>> >>> The client only sends OPEN reclaims after noting the server has >>> rebooted due to previously receiving an NFS4ERR_STALE_CLIENTID or >>> NFS4ERR_STALE_STATEID error from a state-full operation (RENEW, OPEN, >>> OPEN_DOWNGRADE, OPEN_CONFIRM, CLOSE, LOCK, LOCKU) which triggers the >>> client to establish a new clientid via >>> SETCLIENTID/SETCLIENTID_CONFIRM. >>> >>> Upon server reboot, all state that the previous server instance had is >>> invalid - including OPEN seqid's. So, the server returning >>> NFS4ERR_BAD_SEQID (10026) on an OPEN reclaim is illegal. >> >> Wait, but couldn't there be multiple reclaims using the same open owner, >> in which case later reclaims could in theory hit BAD_SEQID? > > Nope. > > 3530 section 9.1.6. Sequencing of Lock Requests > > Note that for requests that contain a sequence number, for each > state-owner, there should be no more than one outstanding request. Well - I sent this too soon :) . Yes, a buggy client could send (serialized) reclaims with a bad seqid, and get NFS4ERR_BAD_SEQ. Tough to do with the above constraint, but possible. -->Andy > > -->Andy >> >> --b.