From owner-freebsd-fs@freebsd.org Fri Nov 2 02:24:21 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 C2F0F10E1BBC for ; Fri, 2 Nov 2018 02:24:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660067.outbound.protection.outlook.com [40.107.66.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B87B71FA3; Fri, 2 Nov 2018 02:24:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM (52.132.50.155) by YTOPR0101MB1212.CANPRD01.PROD.OUTLOOK.COM (52.132.43.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Fri, 2 Nov 2018 02:24:19 +0000 Received: from YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM ([fe80::9c71:6eb6:1bff:727b]) by YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM ([fe80::9c71:6eb6:1bff:727b%3]) with mapi id 15.20.1294.024; Fri, 2 Nov 2018 02:24:18 +0000 From: Rick Macklem To: Andriy Gapon , Konstantin Belousov CC: FreeBSD Filesystems , Josh Paetzel Subject: Re: How to fill in the fsid for file systems? Thread-Topic: How to fill in the fsid for file systems? Thread-Index: AQHUb557F1RNqdJl0kuwS+F5J/DjsKU2/twAgAGdwkKAAGQrgIAAehmGgAELs4CAATs6uA== Date: Fri, 2 Nov 2018 02:24:18 +0000 Message-ID: References: <20181030012240.GM5335@kib.kiev.ua> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1212; 6:DNe8KQiJmtlpbSOoUitwB48nGn6Z+Uq3zgOj0OcKgD4PEXHEHxEioFunMD0QiqZol0My2bHxvs76dt+JykUrdQYJtEQFwXDBPtPuAyqsa6AVCLhmSLoGGJBmOR3JiiiFI0oYpUhh/dqTirBmOK7q+7hl5seUyNZy4FTdZN2PPMMukBuio8Z4mF4yIkhlQl7wqw+lkMUziptXmMfBHXZrXPvJ+2zuJJyJo2PcMkHF4jI36KhikUqPmjuEql7+jP53bakNTLAvu9iD6eXGE40JAIB6kwfESjoy5FGAEYHSKyxP0aMXNbPp9GOhDxOdlkyhSjXknkwJKuc2WPB3MBr32FuG1eF+O9Y/tZbQWzCgQ7Abm2bQZDSvNjw7E0G2dqip8ar4RgucCMBv8xCwuwSdLhimi3HpxMgaTTjbgEbkcskP3BVcSAq39neOsvDiHrSg2NRc7lTk9KRm50FZJ2cptw==; 5:k4uAtptzvZ3m0HPADIy1cLus+z62IV8geegQmjoX3DJQNgRGfbaYkvzGV3STl94wqet7FqmHTUG0mMNL1PpWhBbHaFLJqck+H6617LyWYQTxj9A1vx3SxRrNhLPK0Mi1+L3rSljekLHn6W3esoikXX9/ihyaE7ePCTfqfQud/AQ=; 7:WnnOD2dT50HdCI/xEI6eTqWFO3fVMuMUUueXDyWd8os9IMQjfa3qhCHScapHWpFroYvYoAIA8mlS0AIoofLByvEM2ri1y+HcHwSozNmOL9JpyxiqQ2YL658+k9fn5Ag+LgDVkafuTpVcY+rnUjaf5w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 150e811f-1c6c-4b32-5c05-08d6406a4b13 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1212; x-ms-traffictypediagnostic: YTOPR0101MB1212: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:YTOPR0101MB1212; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1212; x-forefront-prvs: 08444C7C87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(366004)(376002)(346002)(199004)(189003)(86362001)(106356001)(229853002)(305945005)(256004)(186003)(33656002)(105586002)(5024004)(14444005)(46003)(74316002)(6246003)(9686003)(74482002)(55016002)(39060400002)(97736004)(2906002)(5660300001)(316002)(81156014)(81166006)(7696005)(8676002)(93886005)(6436002)(8936002)(786003)(6506007)(68736007)(102836004)(25786009)(53936002)(4326008)(2900100001)(446003)(11346002)(71200400001)(14454004)(486006)(71190400001)(476003)(110136005)(478600001)(54906003)(76176011)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1212; H:YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: UM2/FFORNIkY5XgNCv1nRcQvxG92Nm6A5Q602wC8/Yx4Fu/erIkf8aqrSokRZ95CCiiLKKcT0Sltht7O/+I03GKpltL1A38Akt346ShG5WmTJFDw9I4uypUh5bQHojvdZZ57ma0jZF1rRIWc975VoBqe5mr2MMBdqbfjkEXrtVwOYtwwfhXrzau5kGUsaqYcwDhw44PN36b2Ib57xLj5FDQFoijBEgUuwjnNszvHGPUNijBpVG48HkTRosxMhO9hs5gwC7ihPS9Ps3JOBBkRtKXRywvbhYE5paZEVYFj3oi0gyC7DvGc6vnfC0VRQaJH+31/LRMOThqdxI3mRc/EQjOr7fpASd+U5xIm+SOMDeQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 150e811f-1c6c-4b32-5c05-08d6406a4b13 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 02:24:18.9462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1212 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 02:24:21 -0000 Andriy Gapon wrote >On 31/10/2018 17:50, Rick Macklem wrote: >> I alluded to this option in my last post. I think both fsids will need t= o be in the >> mount structure, since finding the correct mount point via the fsid is t= he first >> step in translating a file handle to a vnode. (After that VFS_FHTOVP() d= oes the rest.) >> >> And I think it will get messy. A couple of examples. >> There are some syscalls that use file handles. fhopen(2), fhstat(2), fhs= tatfs(2), >> getfh(2), lgetfh(2) >> I had assumed that the "file handles" used by these should be the same f= ile >> handles that NFS uses (ie. file handles are a generic VFS component and = not NFS >> specific) but I can see the argument either way. I actually don't know w= hat >> apps/utilities use fhopen/fhstat/fhstatfs, but getfh(2) is used by mount= d. >> Since mountd uses getfh(2) to get a file handle for NFS mounts, it needs= to >> return the NFS fsid to keep the old binaries working, even if you add a >> new getnfsfh(2) function for mountd to use. >> - Now you have some file handle system calls using file handles with the= NFS >> fsid in them and some using file handles with the "true" fsid in them. >> (Sounds confusing to me.) >> >> Since the first step in turning a file handle into a vnode is looking up= the fsid >> in the mount list, if you had two fsids, I think they both would end up = in the >> mount structure so that lookup could be done easily. >> This lookup is normally done by vfs_busyfs() { that appears to be the on= ly use >> of vfs_busyfs() in sys/kern. I haven't looked in the various file system= s }. >> With two fsids, you need two functions and need to be careful which one = you use. > >I originally thought about having a separate filesystem list for NFS that = would >contain only exported filesystems. But I suspect that managing it could b= e >problematic. > >An alternative idea is to use osd(9) framework to attach NFS specific data= to >struct mount without modifying the structure and without exposing the NFS = data >to other consumers. 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 wa= s 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 o= f 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 handl= e would make the code confusing and unnecessarily complex. On the big picture..the more I look at this, the less obvious the usage of = setting an fsid other than what the file system sets seems to become. I thought the= usage of this was to ensure that when a file system was moved (just moving the st= orage hardware or a block by block cloning) to a different system, the same fsid = would be used so that file handles wouldn't change. Note that a file handle also = has a fileid number (think I-node#) in it, so the file system "move" can't chan= ge the file system's structure. - UFS keeps the fsid in the superblock, so moving the file system should re= tain the same fsid value. (There might be an obscure case of another file syst= em having the same fsid, so it has to change. However, since newfs(8) uses t= he creation time and a random# to create it, a conflict seems highly unlikel= y.) - This leaves ZFS. I know nothing about ZFS, but a glance at the code seems to indicate it normally comes out of the "physical dataset" field ds_fsi= d_guid. --> Does this mean it changes when "moved" or stays the same, like UFS? If the answer is "stays the same", I don't see that being able to manually = set the fsid is useful? (There are file systems like cd9660 and msdosfs where the fsid will change, but I don't see those used a storage for NFS servers where they might be moved/cloned/=85) Maybe someone can explain when it would be useful for FFS (or not)? rick