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

Rick Macklem <> Thu, 18 April 2024 02:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A907C14F71C for <>; Wed, 17 Apr 2024 19:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_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 ylut8i0f9jgH for <>; Wed, 17 Apr 2024 19:05:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102a]) (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 35AF8C14F708 for <>; Wed, 17 Apr 2024 19:05:10 -0700 (PDT)
Received: by with SMTP id 98e67ed59e1d1-2a53b331400so307741a91.1 for <>; Wed, 17 Apr 2024 19:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1713405909; x=1714010709;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pL98bzwXRRYVUowhr4vOYl4AGx5fzdAi9P79NKWIIEA=; b=jFmDJZU6kaQrvrtAX64C346nXLNLju/+Vvn6KMHdArm0OfT28y23bUVfYygK0MQ8+L idmkH5kl5v4sAfAwhKBayMg/RyyLRzNBP5mhaBSlg0nZDSqN8YWeb1Wdzj9x5qMYloW4 2nOSGwQybxKomIIWp7dv85Lb1gQbmhIOot6Jg0V6d3XG4x+mP8TJ7s1aPrqQLS06LqEg nz6h3jq0k8j3V5yyvSO+qyE3CqaNsHpTFFtQgPhQCEu+3wK9DCHr1ZCPQhaBHwPTeOnW OWxFqk7J9Lrp7LCpGIyDk9SxamPFcyP6K4yEuz/15uaXT/z2kqc2rsnyqZEbQ50oZ5xh GV5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1713405909; x=1714010709; h=content-transfer-encoding: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=pL98bzwXRRYVUowhr4vOYl4AGx5fzdAi9P79NKWIIEA=; b=uWzXVRIsR8F2H1i8zy/NqS1XCDH913ci1tFCysEN1E8ipikfVopNn5MaH1Rzho8Aug UboGSDcStEZW+KaGg6Ct+MABq1uRMTVZMqaioAF6pk8wfitt083ql6H/XmXiCzQ589tl 4AuCQSyWCt55g5pzJj4WYEwad2T8HAtZOSNYUMEB6TDHbfWyb6F6slrs9Lwf+BwcttqZ 0tJ7WlxoUy8+JuN0nKicB1ZjKHAMHixfbhd+x+qUnxlv9sWtLvvAdsTt77lcnVo6qD9u p78dr/69M/lPAwKJqNwfayMWFxaFbMZwMCOC25Vnl2P42OuO8xsOzfecWMgygydHs5Wd FxCg==
X-Gm-Message-State: AOJu0YxEv/wntGfSx7tRWSOXWkPsEj2I9CytU3E94nFSiHSFg6oS+OXW 32MFPFwQ4ozYS06Ojrj5HwawFU4WOCId126Lfdmbx/CaTp1fHmS6l3pQbRGN7F15c621SxgSbV8 QwMANvF0XxoPb4GJ5+oLyoDmcQw==
X-Google-Smtp-Source: AGHT+IF2xNmyeBy8a1BsnASKek/fsDdUO7JWa8J8UZS5Oidq9yhUAGoPEcTSskcBQoZIh3YNf5WSVJ6g7ph8uH94b78=
X-Received: by 2002:a17:90b:17c7:b0:2a5:f19:978d with SMTP id me7-20020a17090b17c700b002a50f19978dmr1215705pjb.37.1713405909141; Wed, 17 Apr 2024 19:05:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Rick Macklem <>
Date: Wed, 17 Apr 2024 19:04:58 -0700
Message-ID: <>
To: David Noveck <>
Cc: 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: Thu, 18 Apr 2024 02:05:14 -0000

On Mon, Apr 15, 2024 at 4:06 PM David Noveck <> wrote:
> 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".
I did a FreeBSD kernel build with both source and obj trees NFSv4.2
mounted. Here were the RPC counts:
Open/Create     Open/NoCreate     Remove    Rename
30083                9645                      27741       17254
--> So, there were more Removes+Renames than Opens. I have no way
     of knowing for sure, but most all of the files removed/renamed should
     have had delegations. (They would all be on the output obj side.)
Of course these RPC counts are dwarfed by:
Getattr          Lookup
1225717       485257

So, I guess it depends on what you consider as frequent? rick

>> 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