From nobody Fri Jul 21 08:37:12 2023 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R6jbw6FRRz4pM81 for ; Fri, 21 Jul 2023 08:37:32 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4R6jbv6pHJz47kW; Fri, 21 Jul 2023 08:37:31 +0000 (UTC) (envelope-from pen@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se; dmarc=pass (policy=none) header.from=lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CD1621DC4A; Fri, 21 Jul 2023 10:37:23 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id CBB0B1DA5D; Fri, 21 Jul 2023 10:37:23 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -1.0 Received: from smtpclient.apple (unknown [IPv6:2001:6b0:17:f002:1000::2f9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 8C47D1DE84; Fri, 21 Jul 2023 10:37:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: RFC: Patch for mountd to handle a database for exports From: Peter Eriksson In-Reply-To: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> Date: Fri, 21 Jul 2023 10:37:12 +0200 Cc: kevans@freebsd.org, Rick Macklem Content-Transfer-Encoding: quoted-printable Message-Id: <7AC56987-BAB0-4291-8717-2D9EFB2487DB@lysator.liu.se> References: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> To: FreeBSD FS X-Mailer: Apple Mail (2.3731.600.7) X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4R6jbv6pHJz47kW X-Spamd-Bar: --- Regarding the potential for speed improvement here is a quick little = benchmark=E2=80=A6 > # wc -l /etc/zfs/exports > 13116 /etc/zfs/exports With the original FreeBSD 13.2 code: > # /usr/bin/time zfs share -a > 40.08 real 34.00 user 6.04 sys > # /usr/bin/time zfs share -a > 40.15 real 34.06 user 6.04 sys With the DB code in use: > # service mountd stop ; mv /usr/sbin/mountd.DB /usr/sbin/mountd ; mv = /lib/libzfs.so.4.DB /lib/libzfs.so.4 > # rm -f /etc/zfs/exports.db > # /usr/bin/time zfs share -a > 2.75 real 0.88 user 1.87 sys > # /usr/bin/time zfs share -a > 2.77 real 1.01 user 1.75 sys This translates into a shorter boot time if nothing else... - Peter > On 21 Jul 2023, at 10:22, Peter Eriksson wrote: >=20 > Hi! >=20 > Here=E2=80=99s a couple of updated patches with some bug fixes. I=E2=80=99= ve also moved the database location for ZFS to /etc/zfs/exports.db to = mirror the current location. >=20 > I also changed the patch for mountd so that for each =E2=80=9Cexports=E2= =80=9D source specified it first tries to open .db which I think = makes it easier to use (no need for the =E2=80=9C-D=E2=80=9D option and = it supports multiple sources). Cleaner I think. >=20 >=20 > Btw, you can create the database manually from /etc/zfs/exports using = =E2=80=9Cmakemap=E2=80=9D like this: >=20 > makemap -f btree /etc/zfs/exports.db =20 >=20 > Known =E2=80=9Cbugs=E2=80=9D: > =E2=80=9CV4:=E2=80=9D=20 > Even though you could create an /etc/exports.db with the contents of = /etc/exports it will fail with the =E2=80=9CV4:=E2=80=9D lines since the = BTree database will sort the exported entries so that the V4: key will = appear last and then mountd will complain when scanning the DB.=20 >=20 > Also when using the file /etc/exports you can either write = =E2=80=9CV4:/export -sec=3Dsys=E2=80=9D or =E2=80=9CV4: /export = -sec=3Dsys=E2=80=9D (with a space between V4: and the path) so this = probably needs some special handling (can=E2=80=99t simply use = =E2=80=9Cmakemap -f btree /etc/exports.db =20 > I did try to fix that but the code quickly got hairy so I didn=E2=80=99t= like it. If we really want/need that I=E2=80=99m thinking of creating a = special case for the V4: handling, sort of like prefixing the database = key with a NUL byte or something (so that it will be sorted first).=20 >=20 >=20 > Multiline options - well, the current ZFS code doesn=E2=80=99t support = it either so no change from the current setup but it would be nice to = have. > Ie, support for things like: > /export -sec=3Dkrb5 > /export -sec=3Dsys ro >=20 >=20 >=20 > >=20 >=20 > (I also agree that the USE_SHAREDB probably should be removed, I just = have that here for now so that I can quickly disable the code) >=20 > Regarding the patch to the zfs part - I=E2=80=99m not sure which way = to go there - the current patch switches to always use the DB. But one = could argue that the code could check for an existing = /etc/zfs/exports.db and only use the DB-writing code if that already = exists. That way it will support both the old way and the new way, but = it requires an empty /etc/zfs/exports.db to be pre-created at initial = boot time for it to start using it.=20 >=20 > - Peter >=20 >=20 >> On 21 Jul 2023, at 00:50, Rick Macklem = wrote: >>=20 >> Hi, >>=20 >> Peter Eriksson has submitted an interesting patch that adds support >> for a database file for exports. My understanding is that this = improves >> performance when used with the ZFS share property for exporting a >> large number of file systems. >>=20 >> There are a couple of user visible issues that I'd like feedback from >> others. (Hopefully Peter can correct me if I get any of these wrong.) >>=20 >> - The patch uses a single database file and a new "-D" option to >> specify it on the command line. >> --> I think it might be less confusing to just put the database = file(s) >> in the exports list and identify them via a ".db" filename = suffix. >> What do others think? >>=20 >> The changes are #ifdef'd on USE_SHAREDB. I'm thinking that this >> change will be always built, so maybe USE_SHAREDB is not needed? >> (Obviously mountd(8)'s semantics will only changed if/when database >> file(s) are provided.) >>=20 >> Once I have feedback on the above, I will put a patch up on >> phabricator. >>=20 >> rick >> ps: I believe kevans@ has volunteered to shepperd the ZFS share >> property changes. >>=20 >=20