IETF Logo Mail Archive

Re: [nfsv4] changing fileid of a file during a mount

Thomas Haynes <loghyr@primarydata.com> Thu, 08 March 2018 22:28 UTC

Return-Path: <loghyr@primarydata.com>
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 89C54129C6C for <nfsv4@ietfa.amsl.com>; Thu, 8 Mar 2018 14:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primarydata.com
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 4ZP1xbgQlFeI for <nfsv4@ietfa.amsl.com>; Thu, 8 Mar 2018 14:28:01 -0800 (PST)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [63.128.21.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371E8126BF3 for <nfsv4@ietf.org>; Thu, 8 Mar 2018 14:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1520548079; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=7ZZu/XWBxZpyxs3pYfpr63m+WgzJ9fvCKMxbVBtt+S8=; b=drhB9skO/ChUnrU0dditI5p7Sdk8dc672n8V+yLHmXVaYg68DbGCGg91B4ERQ4eTpUdgTWuyHlhQPQxNeL7m9XfEcRRTtQnZBMI6b9hg8QOqLGEOwBMTOueLCzioc3RYlr12Spq7vCBxRlWDXAyskBkb62S0oYIih+q15p5+p/0=
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0024.outbound.protection.outlook.com [207.46.163.24]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-2-SOL3-kY-NhegA2Ri4Do8eQ-1; Thu, 08 Mar 2018 17:27:57 -0500
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1046.namprd11.prod.outlook.com (10.164.166.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Thu, 8 Mar 2018 22:27:54 +0000
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) by BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) with mapi id 15.20.0548.018; Thu, 8 Mar 2018 22:27:54 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: Olga Kornievskaia <aglo@umich.edu>
CC: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] changing fileid of a file during a mount
Thread-Index: AQHTtys3nE6bIfKU3k2dj2prOooSyqPG6w0A
Date: Thu, 08 Mar 2018 22:27:53 +0000
Message-ID: <28CEC610-346C-4F01-BAC9-2AAED94E6C99@primarydata.com>
References: <CAN-5tyEce2x+e6AuYi7vBC-=5nOPvtEbTD1VvLYA_Q9VBcW0fA@mail.gmail.com>
In-Reply-To: <CAN-5tyEce2x+e6AuYi7vBC-=5nOPvtEbTD1VvLYA_Q9VBcW0fA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [63.157.6.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1046; 7:0iJJOLNuKsfKCb+k16bOV8ol2IMC1Ud7k81r6eRA2mHpz+uSgXznxbCrPCJ0/AOYtoglauiM5KhML/H8Bb2vh6O0/Ap2OJKtAzrC0d0YvDWlnA0H2slC6uP3OMwjYgIozyEDIpe9JJ4sJjZyRJ4XRKwicQPuT9y189lSlDbPRPeEVwO5JH18RizwQbT8qQ3MESxUmfJCLqPIm1lKEWPynyCjnH5rB0gPhmpeNnjS4yXEKrM7YSnNerfkb7l16BYY; 20:L0hNBKboF7vO2egQC2bM5dDcKoycVCe+gHjqEUgIEbb3iuW+c56rVJ+6v4BshIVAw17ErnAEaNdhASdCdZtRF7/VGD/BGDnBRvi73ZX4h7/jLqwb5Vab5U8TbBid2a867IztReq3IzKbZrshVnnAKsxsdcEO6ScKv5t8AqV0ny8=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3a401f36-3a66-4720-10f7-08d58543d5dc
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7026125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BY2PR1101MB1046;
x-ms-traffictypediagnostic: BY2PR1101MB1046:
x-microsoft-antispam-prvs: <BY2PR1101MB1046217F5BB4F31BD35708CACEDF0@BY2PR1101MB1046.namprd11.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(177329092695168);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3231220)(944501244)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041288)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:BY2PR1101MB1046; BCL:0; PCL:0; RULEID:; SRVR:BY2PR1101MB1046;
x-forefront-prvs: 060503E79B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(366004)(376002)(39830400003)(346002)(396003)(199004)(189003)(53936002)(99286004)(6436002)(3660700001)(2906002)(8676002)(59450400001)(966005)(97736004)(25786009)(6246003)(508600001)(36756003)(6506007)(5660300001)(83716003)(81166006)(7736002)(68736007)(229853002)(81156014)(6306002)(53546011)(26005)(6116002)(102836004)(3846002)(3280700002)(86362001)(76176011)(6486002)(305945005)(6512007)(105586002)(77096007)(2171002)(8936002)(4326008)(8656006)(2900100001)(66066001)(186003)(6916009)(2950100002)(33656002)(82746002)(106356001)(14454004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1046; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-microsoft-antispam-message-info: lwn6yMMUWemZsx3y9sV+AeSJsQMA2/saV5kHENy9f3FZvimGYglYPk67ekOqG4eG7J9X9h3Y5ddKXlTPoYORKEfVdDDyTes32P4AaklERh8GGWXTx3MWuOaXRpWxxPgXSIQ06TP1Eci5AH4zroAHs8fSnbuL2OTARNZ1wLB127R/UsvgUwxTGSbdchxvLrMlTBlzX1v2ZP5zvds/J6cIaZT606lOn1dS405RQlJHp2xmo2akXFHrO389SRr7TnmwWhTEWHEGV9FPKsx5MBlz9nTVsI+Dcb+hgpsJRBZXQZ5IkERaKBL0thEIcAD5WEP/ZVK65Lzcy2wAmRrVyHicBA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <246DC598084D6C40B19B4A54CF5FA64D@namprd11.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a401f36-3a66-4720-10f7-08d58543d5dc
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2018 22:27:53.8346 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1046
X-MC-Unique: SOL3-kY-NhegA2Ri4Do8eQ-1
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/mTayzJOuZCCTohviVFWUzNo9cPE>
Subject: Re: [nfsv4] changing fileid of a file during a mount
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Mar 2018 22:28:03 -0000


> On Mar 8, 2018, at 2:17 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> 
> Hi folks,
> 
> Is it allowed that the server changes a fileid of a file on a mounted
> file system?
> 
> Client opens a file a gets a filehandle A as well as attributes of fileid=1000.
> Server changes's this file's fileid=2000.
> client request attributes for the filehandle A and gets a fileid=2000.
> 
> What is suppose to happen? Should the client simply update its
> attributes?

No - the fileid uniquely determines the file within the filesystem.

> Linux client at some point used to fail in this case with
> ESTALE. Currently linux client silently ignores the changes in the
> fileid done by the server.

Bisect the change and see what the rational was for it?

> 
> In RFC 7530 I see wording that uses "fileid+fsid" to determine if two
> file handles are referring to the same file or not. But it doesn't say
> anything about if the "fileid" is like a filehandle and suppose to
> remain unchanged for the lifetime of the file object.

If it changes, then it is no longer the same object that the
file handle referred to.

> 
> In RFC 5661 I read about transitions and how in transparent
> transitions, the file handles are persistent and fileid/fsid(s) don't
> change across transitions. But also in section "11.7.4.  Fileids and
> File System Transitions" that talks about transition and how fileids
> are (or could be) changing specially if transition is between
> different vendors and can't preserve fileid sameness.
> 
> But all of this makes me think that on a "non-transition" case a
> server shouldn't be changing a fileid. But I can't find anything in
> the spec to support this.
> 
> Any clarification on this would be highly appreciated.
> 
> Thank you.
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>

v2.23.0 | Report a Bug | By Email