[nfsv4] Current-stateid/special-stateid for Layoutget

Rick Macklem <rmacklem@uoguelph.ca> Mon, 06 March 2017 22:59 UTC

Return-Path: <rmacklem@uoguelph.ca>
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 154BA129552 for <nfsv4@ietfa.amsl.com>; Mon, 6 Mar 2017 14:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6m-E6zrDxhtB for <nfsv4@ietfa.amsl.com>; Mon, 6 Mar 2017 14:59:32 -0800 (PST)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660084.outbound.protection.outlook.com [40.107.66.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CE212896F for <nfsv4@ietf.org>; Mon, 6 Mar 2017 14:59:32 -0800 (PST)
Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Mon, 6 Mar 2017 22:59:30 +0000
Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0947.018; Mon, 6 Mar 2017 22:59:30 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: Current-stateid/special-stateid for Layoutget
Thread-Index: AQHSlspFsadHqC8EgUaSxn+gTjXa4w==
Date: Mon, 06 Mar 2017 22:59:30 +0000
Message-ID: <YTXPR01MB018991790132B7CA9DA22FE5DD2C0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uoguelph.ca;
x-ms-office365-filtering-correlation-id: 543d5c49-8717-4aaf-30b6-08d464e4729f
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0190;
x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:BWlxrHRnPKCtWMGOc66Yv6hymudAoKvBOwe9X6FWc4wUuWSATcgw7dEqIROSKSG9koR2LNHmJfbqXOJ38hsEA0ZbRuVAGeB4py/VXGKBmLDjCFKM/mwcpryGI1jv5hBsNL3NPxh/+GtIB7CK6s0TTd4F3O06OOunZukpCpEKGyDe6AyjfZDGU5mKv/lyjWi1DeOUtPRLtip0NC272fQS26YIWzegv8DyFkZE+uL2Fqz+Q/YBEtawQra2wZ3v63SLwkP8UuYkOaiuJXw26RKnO6quhfqgE6tgdhbNzKgnVFeJ+YrhiUV9onR49uZT3smxcCIBiXqEsQ4BAAAP1icvHA==
x-microsoft-antispam-prvs: <YTXPR01MB0190F5E79C0168C1CDAFE147DD2C0@YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM>
x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190;
x-forefront-prvs: 0238AEEDB0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39830400002)(39410400002)(33656002)(189998001)(7696004)(450100001)(3660700001)(305945005)(74316002)(2351001)(122556002)(5660300001)(9686003)(55016002)(53936002)(2501003)(110136004)(6436002)(2906002)(50986999)(3280700002)(106116001)(38730400002)(102836003)(74482002)(2900100001)(8676002)(92566002)(81166006)(6916009)(77096006)(86362001)(54356999)(6506006)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2017 22:59:30.3657 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/kWOkEuhMOsrFmpr35CiYDnX13uI>
Subject: [nfsv4] Current-stateid/special-stateid for Layoutget
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 06 Mar 2017 22:59:34 -0000

Boring background...
I created a pNFS server using Flex File layout and GlusterFS. It was
a dud. Basically worked, but was very slow.
I came up with Plan B, which is a simple, single MDS server using
File layout and FreeBSD's nfsd. It seems to work pretty well, which
brings me to...

When I have a client mounted with pNFS enabled, I see better I/O
performance for tests on fairly big files, however for software builds
(lots of I/O on small files), the performance is about the same for pNFS
as when pNFS is disabled and all I/O is being done through the MDS.

I am not 100% sure, but when pNFS is enabled, the client does two RPCs
when a file is opened:
- one that does the Open
- one that does the LayoutGet
and I think the extra RPC round trip time slows the pNFS case down.

The obvious fix is to do the Open and LayoutGet in the same compound RPC.
If the client already has a layout for the file, the LayoutGet can use the
Current-FH set by the Open operation and the layout_stateid and life is good.
However, if the client is getting the first layout for the file (this is usually the
case for the File Layout), then it doesn`t work, because LayoutGet needs
an open_stateid argument.

So, here`s what I am thinking of:
- Define a Current-OpenStateID, which is unset at the start of a compound.
- A successful Open op. sets the Current-OpenStateID to the one in its reply,
  so that it is set along with the Current-FH.
- Any other operation that sets the Current-FH unsets Current-OpenStateID.
- Redefine the case of LayoutGet with a special stateid as...
  If the stateid in LayoutGet`s argument is a special stateid, replace it with
  the Current-OpenStateID if one is set.
--> Then, do everything else just as RFC-5661 states.

I don't know about other implementations, but this would be easy to do in
the FreeBSD NFSv4.1 server and would allow LayoutGet to follow Open in
the same RPC, I think? (I haven't actually coded this yet.)

For server's that don't support this, I don't think it would be a problem,
since the compound would fail at the LayoutGet with NFS4ERR_BAD_STATEID.
At that point, the client would have the Open reply and could just do the
additional compound RPC with LayoutGet, using the OpenStateID in the Open
reply.

So, what do others think?

Also, I haven't followed the versioning discussion, so I have no idea if this
can be done without having a new minor version?

Thanks, rick
ps: I will probably code this up in FreeBSD experimentally, to see how it works.