Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-layoutwcc-01.txt
Rick Macklem <rick.macklem@gmail.com> Fri, 17 March 2023 23:19 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 2BCFEC152575 for <nfsv4@ietfa.amsl.com>; Fri, 17 Mar 2023 16:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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 SsEEtPRJu7xG for <nfsv4@ietfa.amsl.com>; Fri, 17 Mar 2023 16:19:55 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 70D94C14CE36 for <nfsv4@ietf.org>; Fri, 17 Mar 2023 16:19:55 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id fd25so4044393pfb.1 for <nfsv4@ietf.org>; Fri, 17 Mar 2023 16:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679095195; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=w9pGFN+E5X3xWs8NK4tPcNeHObsOPA/FayxfAgbS/TA=; b=HhNBJAMkX2VF041nJwlrl6DUG2xB/vx2tH6mnItpGJ5OdWzyNjHCfRSADQdeJH/PAk Zm6VWmmAqP0IFqZJUL6+Vhh2LvgxjOaeYr7zMFH2oGkmrNYm0PPNFNS/1IRWYkImyZaC I5iaQb4NPFXcqDymI46x73GJB9qrpUw6CJN248RuPY2DLk0H0tnD6rNm3ccyOOm1qVTo uV3CM8taFHpS0J+Z7jsVBJh/9HIsVXInLq3POCJQYZg2FaiSEYow2ATUCW0AgCPvEyfE nTPkspLxRTiModeJAvBcJbhFkq+J7pBWN0zIDuXWTJWrsxbJVfZjdbuAcLcS3Al56a1m WW4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679095195; h=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=w9pGFN+E5X3xWs8NK4tPcNeHObsOPA/FayxfAgbS/TA=; b=CXO0hcnUExi4ix7szNX6jCt4lPdglBWDFzAbj9v2//9mpBfyL55+w+CUulLWv2vPQl f9oXg8fVkexCQnLo+mJqDST848/eSyN9JQ5b7wqW0/aRF+qo1GL/xX1GF/WKBWlsM1CN BPJbXSncVvJ2tEeL5KyxMcQJKWbMGac50ZjKkQa/X/ReXaIKV3Nt5quahn4qKo8KX8PF YGuL3KJf7cAIpSgxmaYJmnsMVQFuplzuA174skXgHAe/J8/G9lsMhF3GzlnJArXjhWZx 3KIYqkK6bX74S83dFJwQ4bSgoxLRWHzrZ7aFnrxv9CHxyiy2l8xA+awzxeT3BW1F64jn t09A==
X-Gm-Message-State: AO0yUKWRlkwdyYKuFEkJXEjqVJTIe261QuGMUX/xiFAmiqNdR3Lf8mA4 6JEMx7Bo3a6GB8dscpHFyJKLQSeg34uQ1fkeAA==
X-Google-Smtp-Source: AK7set9aSzsh1o8OmSiRSJoZL2nXp4EvMRt8wLmssC+Yti5XGOBejpNMpl5+yaAA5NpFMwmasDUAsD5pbg3qRvx8U18=
X-Received: by 2002:a65:5c06:0:b0:50b:d724:98e3 with SMTP id u6-20020a655c06000000b0050bd72498e3mr22635pgr.0.1679095194722; Fri, 17 Mar 2023 16:19:54 -0700 (PDT)
MIME-Version: 1.0
References: <167690801491.19966.10073497475444708402@ietfa.amsl.com> <593CEF2C-EE09-4CB7-86F3-E84F3C7E35B4@hammerspace.com> <1681714268.9413960.1679079821291.JavaMail.zimbra@desy.de>
In-Reply-To: <1681714268.9413960.1679079821291.JavaMail.zimbra@desy.de>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Fri, 17 Mar 2023 16:19:37 -0700
Message-ID: <CAM5tNy49hNW08xhmpCZW610P3rz+fhsoYmhyzbkx85oUG-7RYA@mail.gmail.com>
To: "loghyr@hammerspace.com" <loghyr@hammerspace.com>, NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/BfpACxKUXq3CNzBQj02bMXhUNQU>
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-layoutwcc-01.txt
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: Fri, 17 Mar 2023 23:19:59 -0000
Here are a few generic comments... As it stands, I could not implement this in a way that I would think would be useful. - There is no indication when the client should issue this operation to the MDS. I'd suggest something like "whenever the client expects attributes related to writing is up-to-date for a Getattr against the MDS" or something like that. --> As a client implementor, I need to know when to do this.. Which attributes? It doesn't seem to get specific about what attributes. I'd suggest a specific list. Possibly: Size Change TimeModify SpaceUsed and maybe TimeAccess? Change is going to be problematic for NFSv3 DSs. Maybe a mechanism similar to what is defined for handling Change when a client holds a Write delegation can be used? When I did the pNFS flexfile layout client, I did a LayoutCommit whenever the client needs up-to-date attrbute values, because I thought that was what LayoutCommit would be useful for. --> If the client does this, the pNFS flexfiles layout server only needs to get up-to-date attributes from the DS at that point in time and can cache them in the MDS otherwise, unless there are Getattr requests from client(s) that do not do pNFS, such as NFSv3/v4.0 clients. --> I discovered that the Linux client does not do LayoutCommit for some cases where it expects the above attributes to be up-to-date, so I was forced to query the DS whenever the MDS receives a Getattr and any RW layout for the file has been given out. (The description of when to do LayoutCommit is vague in the RFCs. I recall the Linux client doesn't do a LayoutCommit unless it needs to also do a Commit to the DS.) My point is, this situation can be improved if there is a well defined "if the client expects up-to-date attributes, it must do this". In general, for this to be useful for me to implement (client and server), I need more specifics w.r.t. what attributes, when the Layout_wcc must be done. rick > ----- Original Message ----- > > From: "Thomas Haynes" <loghyr@hammerspace.com> > > To: "NFSv4" <nfsv4@ietf.org> > > Sent: Monday, 20 February, 2023 16:48:45 > > Subject: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-layoutwcc-01.txt > > > This version addresses the issue that the draft is NFSv3 Flex Files only. > > > > Thanks, > > Tom > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-haynes-nfsv4-layoutwcc-01.txt > > Date: February 20, 2023 at 7:46:54 AM PST > > To: "Thomas Haynes" <loghyr@hammerspace.com>, "Trond Myklebust" > > <trondmy@hammerspace.com> > > > > > > A new version of I-D, draft-haynes-nfsv4-layoutwcc-01.txt > > has been successfully submitted by Thomas Haynes and posted to the > > IETF repository. > > > > Name: draft-haynes-nfsv4-layoutwcc > > Revision: 01 > > Title: Add LAYOUT_WCC to NFSv4.2 > > Document date: 2023-02-20 > > Group: Individual Submission > > Pages: 9 > > URL: > > https://www.ietf.org/archive/id/draft-haynes-nfsv4-layoutwcc-01.txt > > Status: https://datatracker.ietf.org/doc/draft-haynes-nfsv4-layoutwcc/ > > Html: > > https://www.ietf.org/archive/id/draft-haynes-nfsv4-layoutwcc-01.html > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-layoutwcc > > Diff: > > https://author-tools.ietf.org/iddiff?url2=draft-haynes-nfsv4-layoutwcc-01 > > > > Abstract: > > The Parallel Network File System (pNFS) Flexible File Layout allows > > for a file's metadata (MDS) and data (DS) to be on different servers. > > It does not provide a mechanism for the data server to update the > > metadata server of changes to the data part of the file. The client > > has knowledge of such updates, but lacks the ability to update the > > metadata server. This document presents a refinement to RFC8434 to > > allow the client to update the metadata server to changes on the data > > server. > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] Fwd: New Version Notification for draft-h… Thomas Haynes
- Re: [nfsv4] Fwd: New Version Notification for dra… Mkrtchyan, Tigran
- Re: [nfsv4] Fwd: New Version Notification for dra… Rick Macklem
- Re: [nfsv4] New Version Notification for draft-ha… Thomas Haynes
- Re: [nfsv4] New Version Notification for draft-ha… Thomas Haynes
- Re: [nfsv4] New Version Notification for draft-ha… Rick Macklem