From owner-freebsd-fs@freebsd.org Wed Oct 31 15:50:34 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 A36E310DD944 for ; Wed, 31 Oct 2018 15:50:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670063.outbound.protection.outlook.com [40.107.67.63]) (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 470997BD3C; Wed, 31 Oct 2018 15:50:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM (52.132.50.155) by YTOPR0101MB0842.CANPRD01.PROD.OUTLOOK.COM (52.132.48.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.24; Wed, 31 Oct 2018 15:50:32 +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.021; Wed, 31 Oct 2018 15:50:32 +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/twAgAGdwkKAAGQrgIAAehmG Date: Wed, 31 Oct 2018 15:50:32 +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; YTOPR0101MB0842; 6:MI43b6h+wddc4RfVd5w7w/TAFq/Y21AA3TFOg+4XO41HC/FZlq+HBC4f1OlCQjUgqn1w6o4uMP4/5Rn1NXzlDD9rMKsuFFH9J5qa2npELD8CwCRN6w2Td3e+HwyZhLCwVkCwkvhFvfH2fn6UYTAOC8FuZYwW/SsncDkiR65QssD/h1yI8sVlF8tIlDZQHXm9qvWsUbDI5+cCnLKa4LaHyAZ5ja8Ce93u5Yc5yJ3UYnrC46Ns2dcKnAf4E6Jp0ldCMdcavCzFBKmtIxZiWPo7AFdZtl9xGikDdxOaVBJuxdj18P+9O/4zwoMLzU6g3OPVnr9lRtoW76kA/xDQF928ptLBulum9MIc8cIxaRM1JSlR2gMP3DFHIw7UwbvOLAPFROXIFiHOxTTyKIqMFT+n+jvIKHeoJVg4LGTMNAxB7oRtS0TXNOL0y1GptWMmnwZf7Ge3Y/xY6XiW3J72mWI17A==; 5:fddT1os1ok3MCyr+XUTj8+HgYiOrLGCYe8BlItY4hi8V/gas+aVsrbHvwvg4r6Be7tAwsH08QSbt2pOA0dGiVihodDg+ENSJSI9lsDwTQ8di+ka9PHZ9MTT8YNR7CliqVCMbQmn2xAdvpuD9DWqzaO+XIOflrUcbtikM71yq9nw=; 7:+NDaM1gEY2iNnGumrQbheYd3DEY+NzkLM2tE+Smrce+FkXHyqUPvgIVmhz+zwpVyGPAMYgf7NnnnyOdnLye9ayJZLx2iRThYu351JiJDi5/YyTrf4H0+fvza8rE1kWUVA9GrR4c4bUY6N8UMvmqV3w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bcb208e9-1fba-43c8-50bd-08d63f4896f9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0842; x-ms-traffictypediagnostic: YTOPR0101MB0842: 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)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:YTOPR0101MB0842; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0842; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(346002)(376002)(51444003)(189003)(199004)(6436002)(74482002)(14444005)(55016002)(74316002)(229853002)(305945005)(5250100002)(5660300001)(256004)(110136005)(316002)(54906003)(786003)(2900100001)(93886005)(186003)(478600001)(97736004)(476003)(106356001)(446003)(11346002)(105586002)(14454004)(486006)(46003)(76176011)(6506007)(102836004)(4326008)(71200400001)(68736007)(86362001)(99286004)(33656002)(6246003)(8676002)(81156014)(81166006)(39060400002)(25786009)(8936002)(9686003)(2906002)(71190400001)(53936002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0842; H:YTOPR0101MB1162.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: xCb/vuvN8YM9TWdn1IEBy5rVE8Zyl/12QqL/rETUpwTgsarVeINTm5KgfILvr8Rw9+7rJqDVqgIITLxn6lX4Xo7jLccRn3ba9mDMiSLO0AMUCAZgIho65fpZsr7R9bNATuGsuO79VyoRprzapJ/CrcjSJHu/KAQ8DL7vhT39gBNyMiHZI+GVTLHKfRTQRngjSJPGbjeCYbAVnngsZhKWvnv9HRazBZ5/86lelRoJgcOW0iP9pPQfapLcPJoiwI6YPsK6mAzeXRGkmXkNWgeWYJ+7V8Hyhjd+h3kO0i2pj0eBrw3sj5BPcwsBfKj9TzSPXUQkjOu4WdVi6veReb1xi2eRW0su5GpCZTfvHgRJAVI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: bcb208e9-1fba-43c8-50bd-08d63f4896f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2018 15:50:32.1839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0842 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: Wed, 31 Oct 2018 15:50:35 -0000 Andriy Gapon wrote: >On 31/10/2018 04:23, Rick Macklem wrote: >> Konstantin Belousov wrote: >>> Why do you consider this an option for exports file and not for nmount(= 2) >>> and fstab ? Do you intend to mangle fsid for mount protocol only ? >> Well, Josh Paetzel proposed this. I believe it was because "that's how L= inux >> does it" (but I can't speak for Josh). >> >> The kernel code currently sets this via an nmount(2) option called "expo= rt.fsid". >> Although Josh's patch has this done in mountd.c, it could simply be used= as >> a mount option in /etc/fstab or manual mounting. (The code currently pro= cesses >> this option in vfs_domount_update(), so it would need to be moved to whe= re >> options are processed during mounting, but that wouldn't be hard.) >> >> This would actually avoid patching mountd.c. It would also avoid the fac= t that >> the "export fsid option" applies to all clients and is not per-host or p= er-net. >> (Doing it only for "exports" requires a moderate amount of code change, = such >> as a new function to be used instead of vfs_busyfs() to busy the file sy= stem >> after looking up the fsid in the export stuff. I haven't coded this, so = I'm not >> sure how much work that would be?) >> >> I actually think making it a generic nmount(2) option and not an export = specific >> one sounds like a good idea. >> >> What do others think of making "fsid=3DN" a generic mount option for >> overriding the selection of fsid done by the file system? >> >> rick >> ps: Although I don't try to be "Linux incompatible", I don't see why we = should >> be compatible when doing it a slightly different way seems more lo= gical. > >I see two issues here. > >One is practical. How do we provide fsid to ZFS filesystems? >I mean I would hate to resort to mounting ZFS via fstab just to provide fs= id >whereas today ZFS filesystems are mounted auto-magically. >We could add a FreeBSD specific fsid ZFS property, but that's also some ex= tra code. Good point. I'm not a ZFS guy, so I wouldn't have thought of this. >The other issue is a potential design issue. >Right now there is the "one true" fsid that's embedded into struct mount >(mnt_stat.f_fsid) and NFS uses it to match a handle to a specific filesyst= em. >Obviously, to support the fsid override we have to modify the one true fsi= d. >My thinking is why can't NFS have its own fsid (equal to the one true fsid= by >default) that it would use internally to match the handle to an exported >filesystem... >In that case we would not need to alter the one true fsid (in struct mount= ), we >would just set the NFS export fsid. In that case, I think, it would be na= tural >that the fsid override is provided as an export option. >This, of course, would require a new implementation for nfsvno_getfh() to = use >the NFS fsid instead of vp->v_mount->mnt_stat.f_fsid. Also, nfsd_fhtovp()= would >not be able to use vfs_busyfs(), instead it would do an internal look-up. = Same >for nfsvno_getvp(). >[I think that nfsrvd_compound() would keep using the one true fsid]. If NFS starts to use a different fsid, it would need to change everywhere. >But maybe this is a too radical idea? I alluded to this option in my last post. I think both fsids will need to b= e in the mount structure, since finding the correct mount point via the fsid is the = first step in translating a file handle to a vnode. (After that VFS_FHTOVP() does= 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), fhstat= fs(2), getfh(2), lgetfh(2) I had assumed that the "file handles" used by these should be the same file 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 what apps/utilities use fhopen/fhstat/fhstatfs, but getfh(2) is used by mountd. 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 NF= S 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 th= e 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 only = use of vfs_busyfs() in sys/kern. I haven't looked in the various file systems }= . With two fsids, you need two functions and need to be careful which one you= use. rick