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

Rick Macklem <> Tue, 16 April 2024 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42751C14F6AF for <>; Mon, 15 Apr 2024 19:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4cwp_KbU4PJx for <>; Mon, 15 Apr 2024 19:22:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62f]) (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 C0B7EC14F616 for <>; Mon, 15 Apr 2024 19:22:23 -0700 (PDT)
Received: by with SMTP id d9443c01a7336-1e5aa82d1f6so21269305ad.0 for <>; Mon, 15 Apr 2024 19:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1713234143; x=1713838943;; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qTuGCA8ubOvMk1FYPaXPbVLhhVJ3yGHk+MjZBI4QvXM=; b=VXlOZZf6M8W2+96Z/EXxpu10LGLFo5w4MKCAb3vkWf02ml0kizmV8RNFgV7DrZL4w5 CF/RILWtwfovXXlQo2URnIzTPt1QyK3QbrrbtaD6m/YtKQlO5p/h3Cv4l/4JincAQYXT jKUho8WHI4FrtdRJAL6pZItCcrdD8eW0z9++dTKv+eNJwyD+/wBmeZ4SnXSYUPGNxZYd RxXcwwcYzR514JulzwaSFmtYFgbrKf71SXm96nAmqoveNMAspsPF4sNHEkmS7fhfN15S MZxRilheg+HjeoOcgm6hnW+QOWYJEebrYqr5AC33k+QARc/QyQiEmXJ9Y+yw8vZm5UVt 4MuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1713234143; x=1713838943; h=content-transfer-encoding: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=qTuGCA8ubOvMk1FYPaXPbVLhhVJ3yGHk+MjZBI4QvXM=; b=uhvG9SMYVRIeXDglGwTFpqxDbK+5EAvKHPdcj1LYO0q7qqg6AwYW4DeQa3Xm3lAbCK p5oIWf8Yjm3M88O3eI8SF0h8w5qqk2DB87FTYptDcQEMS8z5A1oSZGJPhqUat9/LGXZ+ Tl0JmR+OJ7kSdqE9Uxist7vFbVqDeDYxKEvmYgjh/NUvVdgQUMXDxTedHJ6KDON67CV3 C/E8CeZGPshiVsFFIysn+hYjLLWVAMjYXgi46vcSn94JEu+rcO1cHPMdP1OgPjOP07+/ xe+pl9hNlfK2Cvm4nKpN7+cmFGBXsq4zjX/K7F6MIhW3zLOvWbCAoQwkknETj77W/Of6 eg+g==
X-Gm-Message-State: AOJu0YzYmbRQGP6uQPXFez5YqA9+cHoFsTphD2RGJ+gt5STJGNvy9fpG Bi5ipzrdZbAJbMogeCTWLrKwLBBaKlFtsSw+ARvwc1ZqGfX0CEeLZpb9+0sh8bmL+byFuIa5+Om gTCp2IhnAQUB/97L4ftzA81H2+K2Lztk=
X-Google-Smtp-Source: AGHT+IFyqIE+a1rhSzqUFewffvqYBa3Lsb0KblXMr6DedZI+pQ8sv2s/AwYBKS/+8iRrS3LlmGF9CQghakhFUKvs6og=
X-Received: by 2002:a17:90a:64f:b0:2a4:79ef:4973 with SMTP id q15-20020a17090a064f00b002a479ef4973mr1865698pje.14.1713234143101; Mon, 15 Apr 2024 19:22:23 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Rick Macklem <>
Date: Mon, 15 Apr 2024 19:22:11 -0700
Message-ID: <>
To: NFSv4 <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 16 Apr 2024 02:22:28 -0000

On Mon, Apr 15, 2024 at 3: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, since it seems that the
> delegation stateid should be sufficient?
> This new operation would be the same as DelegReturn except that
> it would not require a CFH argument.
> 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.
Oops, I should have read the RFC first. I found this snippet:
   The following events necessitate recall of an OPEN delegation:

   *  potentially conflicting OPEN request (or a READ or WRITE operation
      done with a special stateid)

   *  SETATTR sent by another client

   *  REMOVE request for the file

   *  RENAME request for the file as either the source or target of the

I thought that the recall for REMOVE and RENAME only applied to
clients other than the one issuing the operation. However, this might
only apply to cases where the file handles will no longer be valid on
the server?

The FreeBSD NFSv4.1/4.2 server currently only recalls the delegations
for other clients than the one issuing the REMOVE or RENAME.
Is this a bug?


> A similar situation exists for Rename where the destination
> already exists.
> I find this scenario happens frequently during software builds.
> So, what do others think  w.r.t. this new operation? rick