[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
- [nfsv4] delegations are useful?? Rick Macklem