Re: [nfsv4] persistent sessions and compound atomicity

"J. Bruce Fields" <bfields@fieldses.org> Wed, 09 December 2020 22:59 UTC

Return-Path: <bfields@fieldses.org>
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 570A83A178F for <nfsv4@ietfa.amsl.com>; Wed, 9 Dec 2020 14:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fieldses.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BdC0WUhLjk6 for <nfsv4@ietfa.amsl.com>; Wed, 9 Dec 2020 14:59:45 -0800 (PST)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA3A3A1265 for <nfsv4@ietf.org>; Wed, 9 Dec 2020 14:59:45 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id A36256EAD; Wed, 9 Dec 2020 17:59:44 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org A36256EAD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1607554784; bh=O5mlz78lLplhDpSdKGuvhn0idNh2Qkz/PqZSNU2TFjM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wYlUDQ84X3GOkl50gR04Pf3nw6oZZuHaw+koiLnUIgiL2lB5gxaI+266219x1h9LQ 4eo8uIarq3oDwuAE6AF1+ureDfgVbEnD1d0tbJQK5vkoIrkJXTLlHhGzmEfRMNXG61 LHivy/bOR8DboNWRV9Y8yBEV+67ChKoiYcmNf3f4=
Date: Wed, 09 Dec 2020 17:59:44 -0500
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: Tom Talpey <tom@talpey.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Message-ID: <20201209225944.GC24283@fieldses.org>
References: <20201209002639.GC16661@fieldses.org> <93d4e52e-23e6-cf5f-4b0f-50060f4c6151@talpey.com> <20201209144927.GB23889@fieldses.org> <2d94c517-04ba-75b0-9583-4b7eb4aa8ced@talpey.com> <YQXPR0101MB096883BD0B2EBF66D12FC732DDCC0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YQXPR0101MB096883BD0B2EBF66D12FC732DDCC0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/mSAmc8S-odb4gUxUeEO0hgv9y-4>
Subject: Re: [nfsv4] persistent sessions and compound atomicity
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 09 Dec 2020 22:59:47 -0000

On Wed, Dec 09, 2020 at 04:43:59PM +0000, Rick Macklem wrote:
> I would say that the ATOMIC refers to the individual operations of the
> compound. In other words, it must cache the reply to each operation
> when it is completed, in the persistent cache.
> 
> Then, if a retry of the compound is received after a server reboot,
> the reply for the first K operations that were completed prior to the
> reboot are generated from the cache and the remaining N-K are
> performed on the file system to complete the reply. (At least for the
> non-idempotent operations in the compound.)
> 
> For this to all work correctly, I think the server file system would
> need to perform each non-idempotent operation ATOMICALLY as well, such
> that after the reboot the file system is in either the pre-operation
> or post-operation state.

Great, sounds like everyone agrees, I'll calm down.

> rick, who has no intention of ever trying to implement a persistent
> session cache.

I can't decide.  It looks like kind of a pain.  It'll require some
cooperation with the filesystem folks--I think it needs to be integrated
with filesystem journaling somehow.

But I'm not looking forward to someone running into this, and having to
say, "oh yeah, we've known about that bug for decades; just give me
another few months or a year, and I'll fix it right up for you...."

--b.