[nfsv4] delegations are useful??

Rick Macklem <rick.macklem@gmail.com> Sat, 08 June 2024 21:18 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 4D2C0C14F71C for <nfsv4@ietfa.amsl.com>; Sat, 8 Jun 2024 14:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cia8SKucgYR0 for <nfsv4@ietfa.amsl.com>; Sat, 8 Jun 2024 14:18:26 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 7024BC14F6F3 for <nfsv4@ietf.org>; Sat, 8 Jun 2024 14:18:26 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1f700e4cb92so2133495ad.2 for <nfsv4@ietf.org>; Sat, 08 Jun 2024 14:18:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717881506; x=1718486306; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=DN8mOVK00NiPxmZWfAupct+GtHxTocswscm3miVqk8c=; b=KTU9A7HzNBWqcWj83yi2X4OrRZ1Gwugyai3gfT/lFph1EPbwcRKdRGhs3IUK6O/uTS kgpMXw0uBHrFmvhgF58z50uLeZRjM+sjdhUnNT5n4pMSI21Gr+q/vqK1UOXQD9CVUb4p dUPN4BL1SwIo8kyUUm3Mc349r0M3UzafAMBlZVv/wdnVYgaN0Bf6LYBYNu+NJkSb6SGQ OHM9QlwKRHt2GughZj3KjceH388W6ifpKVfUgTX88l7akC9vmbH2+INVQyMfj7Ix9FhT +0EBlR/iyPVcC0V4dY+CKLCNV2T9ktM1sxbZAlK8WTR+I0N3YkZE4t0q2Ak1W7C3lXep P5KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717881506; x=1718486306; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DN8mOVK00NiPxmZWfAupct+GtHxTocswscm3miVqk8c=; b=OfcmgpBLRXcWPC9HDuqOfOxJXbHZ424meK8ZL7bIRb8kZd/22Sknws++yUK/sab7A5 hyNPd22DZTuDU2gOPk4L4hUZ7ilb3abyedyHYT2RrT2jNcGx8PhQokfMWVjik2xsONdh XBjb2wM69fw8Jjq7crLtGsAifFP8pk2XxTvt7AhuOs04tDjLzGShVvUH566YgFg2t+1f M+osfBLnAwF6jGbkSyWMoh7/9ViNuJkuMF2/bId9bReIdyhg5KatM5L2k3lG9EjJuoNS RSF82f7wrjZdtfVYlBbQpFdzoa4dFlOrvPrSK3ge40zzIyM/5QAEg93BVnoJGVFwuhv9 f2Dw==
X-Gm-Message-State: AOJu0YyFCnnQH8r57FDyi96IRyq02B3mTV5TowkdHTVsfVdrHUtbZ+zR MpJnTPB+72hOey/X16rt5Qvqc8qgKPCUJY+jI44wIudiQ63Om4DtSz54WTNo8OSJuXn92Aapvxd JzlTpEmm8gdlPG6Kki8tE9luH8CZC4fU=
X-Google-Smtp-Source: AGHT+IGwu5jra8E4Gte+FEP9+wU4owHkxgkCofYQBsbJi/t2kNf4LtFqfiw3iXaRfMjf276VebMCr6fL8uLEWnYWXPA=
X-Received: by 2002:a17:902:da90:b0:1f2:f63b:4795 with SMTP id d9443c01a7336-1f6d02beb66mr78582285ad.14.1717881505455; Sat, 08 Jun 2024 14:18:25 -0700 (PDT)
MIME-Version: 1.0
From: Rick Macklem <rick.macklem@gmail.com>
Date: Sat, 08 Jun 2024 14:18:15 -0700
Message-ID: <CAM5tNy4MHR-9VzAw8VgKXvXjE_WoqDvq+-taeEHQqY3JxcRYVw@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID-Hash: JJIOHZPRZOB22L2NVCCBVVLY5EGZGST3
X-Message-ID-Hash: JJIOHZPRZOB22L2NVCCBVVLY5EGZGST3
X-MailFrom: rick.macklem@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] delegations are useful??
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/yaLOfoMuJ1rLH5buaqKq9_LE8Ps>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Owner: <mailto:nfsv4-owner@ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Subscribe: <mailto:nfsv4-join@ietf.org>
List-Unsubscribe: <mailto:nfsv4-leave@ietf.org>

Hi,

For a very long time I have been a sceptic when it comes to whether
or not delegations are worth the complexity or effort of implementation.
Part of this is because, long ago, I implemented a caching mechanism
using delegation (NFSv4.0) and non-volatile storage and the results
could best be described as "not very satisfying".

I finally got around to implementing more of the NFSv4.1 (RFC8881)
file delegation semantics (in particular the atomic upgrade from read
to write delegation) and...
Running a simple test (which is a FreeBSD kernel build from sources
on a NFSv4.2 mount (sources and object on the mount), I see:
(Note that, starting in the 3rd column, they are RPC counts, where the
column name refers to the main operation in the RPC.)

Config               Elapsed time (sec) Getattr    Lookup   Access
Open/nocreate Open/create
no delegations  16876                     2341147  495422  225608
1112395           28224
file delegations  12734                      216570  445998  185045
 29056            28224
file and directory12537                     196549   298530  184503
 29056            28224
  delegations

As you can see, the file delegations have reduced RPC counts significantly. The
reduction on Open/nocreate was expected, but I'll admit the reduction
in Getattr RPCs
was not. Directory delegations reduced Lookup RPCs by about 30%, even though
no other client was manipulating the directories during the test runs.
(I cannot say for sure at this time, but I suspect it is because,
without a directory
delegation, it is difficult to determine if another client has updated
the directory
and possibly made a name lookup cache hit  fail.)

I can finally say that I think implementation of delegations is worth
the complexity
and effort.

As you may be aware of, I have been working on a draft to allow clients and
servers to "fine tune" requirements for directory delegations with Jeff Layton.
This is hoped to make them easier to implement.
Please take a look at the draft, found here:
 https://www.ietf.org/archive/id/draft-rmacklem-nfsv4-directory-delegations-03.txt

Thanks, rick