Date: Fri, 2 Nov 2018 15:51:29 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Andriy Gapon <avg@FreeBSD.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, Josh Paetzel <josh@tcbug.org> Subject: Re: How to fill in the fsid for file systems? Message-ID: <YTOPR0101MB116276259B4ACC270BE2C63FDDCF0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <a66b836a-96de-9f07-bf15-18e2895ad124@FreeBSD.org> References: <YTOPR0101MB11620BAF0E206EE36E927A5ADDF30@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <20181030012240.GM5335@kib.kiev.ua> <YTOPR0101MB11621427AF47133A93311E16DDCD0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <e7813a64-59c2-67a1-3471-b32a6ca42ef8@FreeBSD.org> <YTOPR0101MB116207BA89FB66EE9B1AAF01DDCD0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <a831d660-1ed9-ef21-f457-8e1e986b96f2@FreeBSD.org> <YTOPR0101MB11621C0D5F4F4D9BED169110DDCF0@YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM> <4269ff9a-8e11-f441-fbb5-b23a6d8e253b@FreeBSD.org>, <a66b836a-96de-9f07-bf15-18e2895ad124@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 i= s 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 ki= nd of file handle. >>> --> Since the fsid is a key part of a file handle, one kind of file han= dle implies one >>> kind of fsid. >>> I just think trying to create two kinds of fsid and two kinds of file h= andle 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 pot= entially >> 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 th= ink that >> NFS, being in kernel, directly uses VFS interfaces like the mentioned VO= P_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 u= sable >> for fhopen(2) and the like. But I can be wrong again. mountd uses getfh(2) to acquire a file handle at mount time for a client. S= o, for NFSv3 it does use getfh(2) to acquire the "root" file handle for the mount. (Technically, it's the Mount protocol, but since that is required for NFSv3= mounting, you might as well call it NFS and this one needs to be an NFS usable file = handle.) >> >> So, if any of my assumptions is wrong, then you are right, of course, an= d 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 loc= kd >could pass a file handle received "from NFS" to fhopen(2). Good point. SInce the NLM isn't NFS I tend to forget about it. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB116276259B4ACC270BE2C63FDDCF0>