[nfsv4] Should client issue close in stale fh?

"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Thu, 23 August 2018 14:38 UTC

Return-Path: <tigran.mkrtchyan@desy.de>
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 B69E0130DF4 for <nfsv4@ietfa.amsl.com>; Thu, 23 Aug 2018 07:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=desy.de
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 biHKWmuCROIA for <nfsv4@ietfa.amsl.com>; Thu, 23 Aug 2018 07:38:22 -0700 (PDT)
Received: from smtp-o-1.desy.de (smtp-o-1.desy.de [IPv6:2001:638:700:1038::1:9a]) (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 87266130ECB for <nfsv4@ietf.org>; Thu, 23 Aug 2018 07:38:21 -0700 (PDT)
Received: from smtp-buf-1.desy.de (smtp-buf-1.desy.de [IPv6:2001:638:700:1038::1:a4]) by smtp-o-1.desy.de (DESY-O-1) with ESMTP id 303052806E6 for <nfsv4@ietf.org>; Thu, 23 Aug 2018 16:38:18 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-1.desy.de 303052806E6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1535035098; bh=xEYpPqfdzmH4EG2dgjhoVQWpofuJYVjUJGaHMtCG3MA=; h=Date:From:To:Subject:From; b=ejdFRjScUCMSDkQo5rXYIZvtZez8Xyqp3x7GiHXsdT7XTf75UyTg+JfUkou1x/Ax7 CabYGakTnD+XS5oWlRaqM6liRm1IfE/ZWfM3IuEIPniIqK4wZMjeM2kLDdR030Uidr WnqcKKjuOxqlylD4Dc1iyxHwzSBx3GkuciZFkZeA=
Received: from smtp-map-1.desy.de (smtp-map-1.desy.de [131.169.56.66]) by smtp-buf-1.desy.de (Postfix) with ESMTP id 2C56C1201D4 for <nfsv4@ietf.org>; Thu, 23 Aug 2018 16:38:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at desy.de
Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by smtp-intra-3.desy.de (DESY-INTRA-3) with ESMTP id B15CA15D2 for <nfsv4@ietf.org>; Thu, 23 Aug 2018 16:38:17 +0200 (MEST)
Date: Thu, 23 Aug 2018 16:38:17 +0200
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: NFSv4 <nfsv4@ietf.org>
Message-ID: <1965353031.38280844.1535035097495.JavaMail.zimbra@desy.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF61 (Linux)/8.7.11_GA_1854)
Thread-Index: JuP3pb34qqvfgGZYGGZjx9GawMfF6A==
Thread-Topic: Should client issue close in stale fh?
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Tk6GJ4vc-N4Tq-Vf0tIQqZCOe_E>
Subject: [nfsv4] Should client issue close in stale fh?
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 23 Aug 2018 14:38:25 -0000


Hi NFSv4 gurus,

we have a following situation. A file, opened by
client-A get delete by client-B before LAYOUTGET
is called:


client-A -> server : OPEN(file)
server -> client-A : fh

client-B -> server : REMOVE(file)
server -> client-A : OK

client-A -> server : LAYOUTGET(fh)
server -> client-A : ERR_STALE


Client-A never sends close. The spec is not
clear about it. Well, I understand, that probably
if file is opened, then file handle must still be
valid, but (a) this is hard to implement for distributed
systems and (b) NFS4ERR_STALE is valid reply to
LAYOUTGET.


Thanks,
   Tigran.