Return-Path: Received: from mail-eopbgr670046.outbound.protection.outlook.com ([40.107.67.46]:34640 "EHLO CAN01-TO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751263AbeEMMMe (ORCPT ); Sun, 13 May 2018 08:12:34 -0400 From: Rick Macklem To: "linux-nfs@vger.kernel.org" Subject: Re: NFSv4.1 client recovery of opens after server crash/reboot Date: Sun, 13 May 2018 12:12:33 +0000 Message-ID: References: In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org List-ID: I wrote: >I just ran a little test of an NFSv4.1 server (FreeBSD) reboot while the Linux client >had two files open over an NFSv4.1 mount (linux-4.17-rc2). >It basically worked, but when I looked at the packet trace in wireshark, it wasn't what >I expected. >The operations were basically: >1 - ExchangeID >2 - CreateSession >3 - ReclaimComplete >4 - Open/Claim_FH done twice to reclaim the Opens > >This seems "unsafe" to me, since I think it would be possible for another client to >Open the file with OPEN_DENY_BOTH between #3 and #4, causing #4 to fail. >I was expecting something like: >1 - ExchangeID >2 - CreateSession >3 - Open/Claim_previous done twice to reclaim the Opens >4 - ReclaimComplete I forgot to mention that this is probably not a serious issue right now, since most extant clients (FreeBSD and Linux I think?) always do Opens with OPEN_SHARE_DENY_NONE. The only current client I am aware of that does OPEN_SHARE_DENY_xx other than NONE is the ESXi 6.5 client. Btw, this client has serious issues that I might post here, so the Linux server maintainers are aware of them. rick