IETF Logo Mail Archive

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

Rick Macklem <rick.macklem@gmail.com> Thu, 18 April 2024 02:05 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A907C14F71C for <nfsv4@ietfa.amsl.com>; Wed, 17 Apr 2024 19:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylut8i0f9jgH for <nfsv4@ietfa.amsl.com>; Wed, 17 Apr 2024 19:05:10 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 35AF8C14F708 for <nfsv4@ietf.org>; Wed, 17 Apr 2024 19:05:10 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2a53b331400so307741a91.1 for <nfsv4@ietf.org>; Wed, 17 Apr 2024 19:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713405909; x=1714010709; darn=ietf.org; 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; d=1e100.net; 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: <CAM5tNy407R30WQqCuzFE+feRz42wkaAAGOwiHwqFoWZSpwfT0A@mail.gmail.com> <CADaq8jfpmBzqWfjEHxA2wZ=Z1=0ExwYBT7TJkyiqvOj+AQq_xA@mail.gmail.com>
In-Reply-To: <CADaq8jfpmBzqWfjEHxA2wZ=Z1=0ExwYBT7TJkyiqvOj+AQq_xA@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Wed, 17 Apr 2024 19:04:58 -0700
Message-ID: <CAM5tNy697LSS-Pg=uAE9NmDtpchn1xrC9Q8RiJ7vN88dOaWpJw@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/0gLGDJQvV_r-UulWlEY2z_wh9nE>
Subject: Re: [nfsv4] RFC: New DelegReturn_NoFH operation for NFSv4.2?
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2024 02:05:14 -0000

On Mon, Apr 15, 2024 at 4:06 PM David Noveck <davenoveck@gmail.com> wrote:
>
>
>
> On Mon, Apr 15, 2024, 6:31 PM Rick Macklem <rick.macklem@gmail.com> 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
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4

v2.23.0 | Report a Bug | By Email