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.
- [nfsv4] persistent sessions and compound atomicity bfields
- Re: [nfsv4] persistent sessions and compound atom… David Noveck
- Re: [nfsv4] persistent sessions and compound atom… Tom Talpey
- Re: [nfsv4] persistent sessions and compound atom… J. Bruce Fields
- Re: [nfsv4] persistent sessions and compound atom… bfields
- Re: [nfsv4] persistent sessions and compound atom… Tom Talpey
- Re: [nfsv4] persistent sessions and compound atom… Rick Macklem
- Re: [nfsv4] persistent sessions and compound atom… J. Bruce Fields
- Re: [nfsv4] persistent sessions and compound atom… Tom Talpey
- Re: [nfsv4] persistent sessions and compound atom… J. Bruce Fields
- Re: [nfsv4] persistent sessions and compound atom… J. Bruce Fields
- Re: [nfsv4] persistent sessions and compound atom… David Noveck
- Re: [nfsv4] persistent sessions and compound atom… Trond Myklebust
- Re: [nfsv4] persistent sessions and compound atom… David Noveck
- Re: [nfsv4] persistent sessions and compound atom… Rick Macklem
- Re: [nfsv4] persistent sessions and compound atom… J. Bruce Fields
- Re: [nfsv4] persistent sessions and compound atom… Trond Myklebust
- Re: [nfsv4] persistent sessions and compound atom… Trond Myklebust
- Re: [nfsv4] persistent sessions and compound atom… J. Bruce Fields