Re: [nfsv4] RFC: New DelegReturn_NoFH operation for NFSv4.2?

David Noveck <> Mon, 15 April 2024 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BD70C15108C for <>; Mon, 15 Apr 2024 16:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id shEQRKSPfwK3 for <>; Mon, 15 Apr 2024 16:06:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 6E619C151083 for <>; Mon, 15 Apr 2024 16:06:44 -0700 (PDT)
Received: by with SMTP id 6a1803df08f44-6962e6fbf60so34415586d6.1 for <>; Mon, 15 Apr 2024 16:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1713222403; x=1713827203;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gohSJbiMhyCn0UlJcmi6fV95eW8a0NaY4nX4Qn6EOUw=; b=IQ5B5xY+HGrlbKixMxtH3w2s25dQnRwzF68y3BMp9PPsgZ8SZMujV0RvTrdMG2X4s6 uxm9lWDbbPWJ7UiTYVbx4VgAfcuWfnmIH9ZPBAjPsYMAPiY7o4c+I+4dSQE/7hV5/mgJ KZQAPebUY4a1jS1lu4OwemNUgwfIk1whenHSN3kFVaLS9vYyTzlcTOdWHkIanNAk10Ro cnSIu61i+0wQPHJ4aomtFGUrc0qQEf5PhYSttW804OM5GXp6y115+A0wJfinnwbfoTx6 BoMtEDWmR0goSWpurJt3E1G/5ZeOD9SpFXprGnGAqZUvoYd4PSKBqQvFXd7PArbINfud iI4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1713222403; x=1713827203; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gohSJbiMhyCn0UlJcmi6fV95eW8a0NaY4nX4Qn6EOUw=; b=Juxf1MndQCXXw8lnn9SUBsyUFAxifUjo5WZiCi/LKEERCBmA3iOkpe4Ib+kHZrkknU ciHpHbeM8yQ9ohiBzagF/2IKqPGteh+DJ2eCekoEqSUke+9oY8JoTru+H8/VFpf+74WG SSwg8ffukjptUp/xW8eaQSjgt0QjDvaioul5QN7I/WC8oOtPkxgO342W2gTBxF4PauHz Zh3n++XNz/WNEWtGLXnteDT2VUN70O71nGILaqAglOUEGV8kL02PplVwJ+lJEqLArOVJ tly68SxuGVdpwx92CtCuu9V1lRGHoFmDfMCrX65c563/V+kXwtl3F3EYEe+lv62JngQu 3fNA==
X-Gm-Message-State: AOJu0YzVEaKtsUhdwqk5jsqeBHfcOS3O2YDWtrW3u3P5d472nJVPzak4 vzFsPkIkQzPt13Ztaf1HURAyM0WgXqWeTd+QaPp+dgzYQ/eyRoKiZmzep9DCdoQ4JZS5BD6JVSK FaW9MuStOR5++Vc89W1Gx7eepHFGZ0A==
X-Google-Smtp-Source: AGHT+IHwMnyR9+Tk7S/BcxkALGPJoJWdzLQ89GaZurYOHfHVpZzpGmSJIRJXiii890Hwnqt+TO56sn+g5nwPEvispy4=
X-Received: by 2002:a0c:db92:0:b0:69b:7c0c:8dff with SMTP id m18-20020a0cdb92000000b0069b7c0c8dffmr4457074qvk.10.1713222402832; Mon, 15 Apr 2024 16:06:42 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Noveck <>
Date: Mon, 15 Apr 2024 19:06:31 -0400
Message-ID: <>
To: Rick Macklem <>
Cc: NFSv4 <>
Content-Type: multipart/alternative; boundary="000000000000be071706162aac67"
Archived-At: <>
Subject: Re: [nfsv4] RFC: New DelegReturn_NoFH operation for NFSv4.2?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2024 23:06:46 -0000

On Mon, Apr 15, 2024, 6:31 PM Rick Macklem <> wrote:

> Hi,
> I am wondering if others have found this a pita and are interested in
> a new operation for NFSv4.2 to get around it.
> Right now DelegReturn requires a CFH and delegation stateid.
> I do not know why the CFH is needed,

I don't think it is needed, although it is REQUIRED.

since it seems that the
> delegation stateid should be sufficient?

It should be.  As far as I can figure, it is most likely  due either to
inertia or a belt-and-suspenders approach to operation input.

> This new operation would be the same as DelegReturn except that
> it would not require a CFH argument.

It would be more correct to say it does not use the cfh as input.

> Why am I interested in this?
> - Lets assume a NFSv4.2 server that supports persistent FHs and
>   multiple hard links (as most extant servers do).
> - A client mounted to this server is removing a file for which it holds
>   a write delegation and a bunch of dirty data.
> Right now, the client must:
> - Write the dirty data back to the server.
> - DelegReturn
> - Remove
> because the client has no way of knowing if the file will be deleted
> by the Remove (or alternately is just removing one of several hard links).
> With a DelegReturn_NoFH, the client could:
> - Do a compound RPC with
>   Remove
>   PutFH of file
> - if the above returns NFS_OK, the file still exists and the client
>   can continue to use the delegation, writing the dirty data back
>   to the server sometime later (or maybe never, if the file gets
>    deleted by a subsequent Remove).
> or
> - If the above returns NFS4ERR_STALE for the PutFH, the file
>   has been deleted. It can throw the dirty data away and
>   DelegReturn_NoFH the delegation.
> A similar situation exists for Rename where the destination
> already exists.
> I find this scenario happens frequently during software builds.

I see that this can happen.  I'm not sure about "frequently".

> So, what do others think  w.r.t. this new operation? rick

I think you have made a reasonable case for this.  I suggest you submit an
I-D defining thus extension.  One issue you would need to address would be
providing a way for the client to determine if server support is present.

> _______________________________________________
> nfsv4 mailing list