[nfsv4] RFC: new MUTEX_BEGIN/MUTEX_END operations
Rick Macklem <rick.macklem@gmail.com> Thu, 08 August 2024 20:36 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 C8A81C15792A for <nfsv4@ietfa.amsl.com>; Thu, 8 Aug 2024 13:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 M4CQHfIX1_b4 for <nfsv4@ietfa.amsl.com>; Thu, 8 Aug 2024 13:36:35 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E879C151535 for <nfsv4@ietf.org>; Thu, 8 Aug 2024 13:36:35 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2cb6662ba3aso980340a91.1 for <nfsv4@ietf.org>; Thu, 08 Aug 2024 13:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723149395; x=1723754195; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=fhd8meB79u8Whyy7TDAUIanxhnoD1VYqSxqUYUCqAK4=; b=LvDRqjSKCEfobkkBlbiHlysiKo+TzvS/e23nlUx+ZAxpz9zQokcqUlAWADYC7WvmCO yV9AlLy2HffhDCONxqoQQlBKB9glipSSCgIqgNyNSuC+MczG3+pSJScrpz2eMSBVqlnD 2mYdxFSLyDnnHK12dSC0O5kJHmNUSX1NnxH5M8iL/Au0Yk8543+BBCmMxlobg1q75nmY 3VJmx8PC2bKB6Rqj61Wd9V6dHWa0JzGMYqGQt+bhC5gGGHerqVmwqHsnS466DSTZ5t24 yVqmRVWZZVp0YKExtYu0o+qWnUryY6z/UJM67rHj2KULTiBuzRZnm68jQUXAPfS8DXod lN5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723149395; x=1723754195; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fhd8meB79u8Whyy7TDAUIanxhnoD1VYqSxqUYUCqAK4=; b=gtAPiFg10qrkKVYuVRn5UnrqFpVYTGh1FaG6OPxXStRI3jr+rUwpPGXyYne5pOA3c4 hrIzc21Ayv0/fIOuKSZlCt6sG0Y6GVJVjwrR4v9OD1j4rDkdQw/ToDyeuAkNIlEhOl+q hVU0Lu7KWIIcAdi28ELju/Zu5plZ27gAP1bqudKYkbkKr7eEoA7ALfW1dqfOx1bHEcA1 tD84Rvsb8oVlmDTsmjYkuytIk+U38/UU6EyQGuF9TYOrBE9AufDtSevldMSXDmcFJhqK 1Yzq1AYf/rD+sNV62iOWLqo2aMkS9X7if9JxDEaulxGEadM+m7nRKInXO2rAnzL7Xgth D7FQ==
X-Gm-Message-State: AOJu0YzgpigBF/uhc/xb6ynVDWbJ9ywxHlh8TP+aaAnHf/gIa1+OBp23 3+XCfEtyH6TUHtiDZcnQ+S/km+qB+9C4e25OLKRoI+OS2vcrJfLL8zS3eU8dIjVtrA2oZlyp71a HrhGfMAzbEFmS8EGY98ZMa3koUKx/
X-Google-Smtp-Source: AGHT+IGuStfi7aKZNUE55UrGys5S9qiVpQN7T17/SbV5+72uny3oudy5MrI5/z3TQMh157OSWetaythKvXGQsTxHeQQ=
X-Received: by 2002:a17:90a:708a:b0:2c9:6753:6192 with SMTP id 98e67ed59e1d1-2d1c4fc85f1mr4670010a91.12.1723149394602; Thu, 08 Aug 2024 13:36:34 -0700 (PDT)
MIME-Version: 1.0
From: Rick Macklem <rick.macklem@gmail.com>
Date: Thu, 08 Aug 2024 13:36:25 -0700
Message-ID: <CAM5tNy7g+YCiiZQD7G6Ryv_Mo8N5BeRiqMP=224zPpEXa+Yi+A@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f7510061f31fb2b"
Message-ID-Hash: K2AM3LMCAD5TOQAZPXQWDTFNW7IML3DZ
X-Message-ID-Hash: K2AM3LMCAD5TOQAZPXQWDTFNW7IML3DZ
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] RFC: new MUTEX_BEGIN/MUTEX_END operations
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/U0z9w_sVocyWLtEkSPTA7LxXiYA>
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, Over the years, I've run into cases where it would be really nice to be able to perform multiple NFSv4 operations on a file without other operations done by other clients "gumming up the works" by changing the file's data/metadata between the operations in the compound. So, what do others think about an extension to NFSv4.2 that adds 2 new operations: MUTEX_BEGIN(CFH) MUTEX_END(CFH) Both would use the CFH as argument, and no other client would be allowed to perform operations on the CFH between the MUTEX_BEGIN and MUTEX_END. I think there would need to be a couple of properties for these: - There would need to be an "implicit" MUTEX_END when any operation between MUTEX_BEGIN and MUTEX_END returns a status other than NFS_OK. - I think you would want a restriction of only one mutex for one CFH at a time in a compound. Without that, there could easily be deadlocks caused by other compounds acquiring mutexes on the same CFHs in a different order. - Only one compound can hold a mutex on a given CFH at any time. - MUTEX_BEGIN/MUTEX_END can only be used in compounds where SEQUENCE is the first operation. - All mutexes are discarded by a server when it crashes/recovers. (Any time a client receives a NFS4ERR_STALE_CLIENTID.) That way RPC retries after a server reboot should work ok, I think? I am not sure what the semantics for reading data/metadata should be, but I was thinking that would be allowed to be done by compounds for other clients for the CFH. If a client wanted to serialize against other compounds for the CFH, it could do a MUTEX_BEGIN/MUTEX_END. I see this as useful in a variety of ways: - The example in the previous email of: MUTEX_BEGIN NVERIFY acl_truform ACL_MODEL_NFS4 SETATTR posix_access_acl MUTEX_END - Append writing: MUTEX_BEGIN VERIFY size "offset in WRITE that follows" WRITE "offset" etc MUTEX_END - A bunch of cases where NFSv4 lacks the postop_attributes that were in NFSv3. MUTEX_BEGIN WRITE GETATTR size, change,.. MUTEX_END So, what do others think? (This was obviously not possible without sessions.) rick
- [nfsv4] RFC: new MUTEX_BEGIN/MUTEX_END operations Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Tom Haynes
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Pali Rohár
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Chuck Lever III
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Jeff Layton
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Pali Rohár
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Jeff Layton
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Jeff Layton
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Jeff Layton
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Pali Rohár
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Trond Myklebust
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem
- [nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operat… Rick Macklem