From owner-freebsd-fs@freebsd.org Fri Nov 2 11:36:22 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BE1010F309B for ; Fri, 2 Nov 2018 11:36:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4D7D841D3; Fri, 2 Nov 2018 11:36:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wA2BaAnM056958 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Nov 2018 13:36:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wA2BaAnM056958 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wA2Ba9E5056957; Fri, 2 Nov 2018 13:36:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 2 Nov 2018 13:36:09 +0200 From: Konstantin Belousov To: Andriy Gapon Cc: Rick Macklem , FreeBSD Filesystems , Josh Paetzel Subject: Re: How to fill in the fsid for file systems? Message-ID: <20181102113609.GL5335@kib.kiev.ua> References: <20181030012240.GM5335@kib.kiev.ua> <4269ff9a-8e11-f441-fbb5-b23a6d8e253b@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 11:36:22 -0000 On Fri, Nov 02, 2018 at 08:53:22AM +0200, Andriy Gapon wrote: > On 02/11/2018 08:45, Andriy Gapon wrote: > > On 02/11/2018 04:24, Rick Macklem wrote: > >> I have two comments. The first is related to the above and the second is a big > >> picture question related to doing this. > >> > >> Specifically w.r.t. the above. I probably rambled and didn't make what I was > >> trying to say clear, so I'll try again... > >> - getfh(2) returns a file handle that is used for NFS, but is also used for system > >> calls (fhopen(2), fhstat(2) and fhstatfs(2)) that are not related to NFS. > >> --> A file handle isn't really NFS specific, although NFS is the big user of it. > >> If the above is correct, then it seems that there should only be one kind of file handle. > >> --> Since the fsid is a key part of a file handle, one kind of file handle implies one > >> kind of fsid. > >> I just think trying to create two kinds of fsid and two kinds of file handle would > >> make the code confusing and unnecessarily complex. > > > > As as far as I understand, VFS calls like, say, VOP_VPTOFH fill only the file ID > > portion of the file handle, fh_fid. fh_fsid is left to a caller, so potentially > > we could already have a discrepancy there (but we don't). > > > > Also, I do not think that NFS uses getfh(2), but I could be wrong. I think that > > NFS, being in kernel, directly uses VFS interfaces like the mentioned VOP_VPTOFH. > > > > I am not sure if getfh(2) has any requirement that its result should be > > compatible with anything NFS. My impression is that it should only be usable > > for fhopen(2) and the like. But I can be wrong again. > > > > So, if any of my assumptions is wrong, then you are right, of course, and I > > should withdraw my argument. > > Thanks! > > > > Looking through the actual code, it appears that rpc.lockd (and only it?) could > be mixing NFS and local file handles... I suspect, but not sure, that lockd > could pass a file handle received "from NFS" to fhopen(2). I believe userspace nfs server implementations exist, and they have to use fhopen(2).