From owner-freebsd-fs@freebsd.org Fri Nov 2 14:03:51 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 111D410F7E62 for ; Fri, 2 Nov 2018 14:03:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80FED6C1AD for ; Fri, 2 Nov 2018 14:03:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it1-x133.google.com with SMTP id k206-v6so3293269ite.0 for ; Fri, 02 Nov 2018 07:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=swkaXV4lgrehlwlObbJM1qCX/VPkAxUu0azitj2QHrQ=; b=OyOPYYuM0L0L8R9vIiRd8t/HpDH3ZM1c6GZd9e8aIwD7RFvZKt/DJ1ZUrm1LMjWqEJ Ixw5vPCYdTHJJPuWo595VUR5fWzjpA6Lit2i73T1e/nufXe08KyRkAzuLLsGyrrEbt6C Rg0FOhyx5f3ZGF6To+SHHBGr6x2yWIz8WKDQ7IvJBMDJn1Z1dPpBSsNUqI3SRXXXws3A 8aYXaJkeIHH+dpo2bl/utKaGvvoeWmzm6K7bcOY/BRgphN5wFDFR/6MMJ7+ozv1DZW1t wgq3QpIms8vNWlUOuedeMsiftEV4rjFK5EMI9GWKxNs/BPNeXP5aXFzRg2Z9DkL5Nst4 zeBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=swkaXV4lgrehlwlObbJM1qCX/VPkAxUu0azitj2QHrQ=; b=pmdd9hsys3PbaIgZ2x8JHVRcqdAlqbZLDCb/yHauVWQc4ziaSGGDjq903js3u+gt3g OAdVLHBZ9L9HujOidMZECEFPpEL/GLhBGT3z1vn5aiGgKVVttqdytlzQhNTybkeu6tdR iZvu/yPu+AdY7KBSEhNaEa08UCCpzZwzRB5bUmySMxELAE02uu032VetrkPv3ts31Rc4 BAk5dkJ5lurJAt1b0uwAm2dFUD1kugvnuycz/zbEG07COrO5WhDvZEEv83zfs6uMCtx8 86wRHUdv20i5NHJX5X+f4fA/0NIyVgqUCDAOS/gmobG76EH8NT71qcTAGn2BngWLmrAr MoOw== X-Gm-Message-State: AGRZ1gIphkm1eaOjwjjsh8hqpnvD8Y8+iPw0x+nstPcdluw7ckPv9aUT p2scOyhDtfxWhFrUw55aD+g9v5gUI06a7FmFKpsuCQ== X-Google-Smtp-Source: AJdET5drVa0DGsJ15e6RWhghEd5wZaEAx5TfEIvuqZ7rPNy5aFHlxNX+gWNhV1o9eCSfoqPY1kxTcwJSzKg0v/XYxqA= X-Received: by 2002:a24:eb0b:: with SMTP id h11-v6mr85733itj.47.1541167429655; Fri, 02 Nov 2018 07:03:49 -0700 (PDT) MIME-Version: 1.0 References: <20181030012240.GM5335@kib.kiev.ua> <4269ff9a-8e11-f441-fbb5-b23a6d8e253b@FreeBSD.org> <20181102113609.GL5335@kib.kiev.ua> In-Reply-To: <20181102113609.GL5335@kib.kiev.ua> From: Warner Losh Date: Fri, 2 Nov 2018 08:03:38 -0600 Message-ID: Subject: Re: How to fill in the fsid for file systems? To: Konstantin Belousov Cc: Andriy Gapon , FreeBSD FS Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 14:03:51 -0000 On Fri, Nov 2, 2018 at 5:37 AM Konstantin Belousov wrote: > 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). > You are correct. NFS is the reason these interfaces exist because it has historically (or at least initially) been implemented in userspace. Warner