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

Rick Macklem <rick.macklem@gmail.com> Mon, 15 April 2024 22:31 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 75F34C14F6ED for <nfsv4@ietfa.amsl.com>; Mon, 15 Apr 2024 15:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YhAnxlsJtXwy for <nfsv4@ietfa.amsl.com>; Mon, 15 Apr 2024 15:31:23 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 1223EC14F618 for <nfsv4@ietf.org>; Mon, 15 Apr 2024 15:31:23 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2a528e7f2b6so2726497a91.0 for <nfsv4@ietf.org>; Mon, 15 Apr 2024 15:31:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713220282; x=1713825082; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Cf+hh0Ks+jCoB+l0gPLApAgzjxRcrRpPRd5t7xoSWx8=; b=GP7PkhxBxn8tiAL4/toiLnOn1kvsg/wEe6iAYpmc0lRKGSJqt/3EfpcDysVmDFVS9k LVy9PpNb0yTLdkHdakw5XS+Pf3YrykLKdmZzEqE/BluuKg21cZC6ftCUvBKJuvLKfFXQ 6lx++5RCVRcYEZtIWXmEvHRIRhtO/z+wNvFsYlODxg9xZoe8tqq2zkblqPAuJLeodDbC 4uW5M7JofjZk7Wk7PNoybEMFPokvhpL+LFc/S+GPYIKYuqriDSXm+sUm61zoSf/eJQcG FonyvtleUs2JADGruTTjYoJvJkwgpUWJVV3RQ/VlfQ33KtawtrP3xsNDGZXohytyQ3yP 1aXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713220282; x=1713825082; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Cf+hh0Ks+jCoB+l0gPLApAgzjxRcrRpPRd5t7xoSWx8=; b=c6uJn5CQcTGxlsZOxVKBZjF774EOWBmgaYvccFve3CYrOmQF7djR9RhgRzBYxS2ih0 a3O9GwGA0TczGZLh1qnyAdecjFxhM7+slry470rxGWzeeX+uD+70eoGgSLmPgX88uJvC kuIaNrz+QL96+6xb6mwP+QuDtVwBGNqBKoUrDSbdM8r3q1JgFBJfpLN4DMI+7Ut3JjuU kUbnrR3Acw6IDbxJ4OYYcPGBEdIEmr9Sr65ZXqFU8AmFOyhFb95LhP5HhS3iSSdCCNis s2ujMTF9bmZqzPgqyLDIcdk/FGVJ/GNjQRniOZ4eq9E8uyX+HXph69EY6JAyrxUKWcvg q6bA==
X-Gm-Message-State: AOJu0YyjfkxLZs12nGYgJqsnuznyq9PVbknrL8I8aI4GNifcsvA0em7k PfxGiBTsGkEu8w4S3UVXAivYSh6lNrzxf5p+HZz/ioiSxYbSWUKN5zYZko8IREgHMvGZszLxKpW 1aRLxMnBqUTVsWRiCjGeHAeQmY8bs
X-Google-Smtp-Source: AGHT+IE8e22sz//kGhLdEJbC0iGce1VvwxrEQM7TghndZgeaFj/ijo9BGB7MBu/UU7vizoJezcF5ZsJqTl4wsZMxBE8=
X-Received: by 2002:a17:90a:1150:b0:2a0:215f:dc9c with SMTP id d16-20020a17090a115000b002a0215fdc9cmr9337066pje.35.1713220282169; Mon, 15 Apr 2024 15:31:22 -0700 (PDT)
MIME-Version: 1.0
From: Rick Macklem <rick.macklem@gmail.com>
Date: Mon, 15 Apr 2024 15:31:11 -0700
Message-ID: <CAM5tNy407R30WQqCuzFE+feRz42wkaAAGOwiHwqFoWZSpwfT0A@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/vDD89jntKu9cE_Y3v1e6_xfzc-E>
Subject: [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: Mon, 15 Apr 2024 22:31:23 -0000


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

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