From nobody Sat Nov 25 05:07:45 2023 X-Original-To: dev-commits-src-all@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 4ScfxS4rCPz529HQ; Sat, 25 Nov 2023 05:07:56 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ScfxR4YGJz4SZZ; Sat, 25 Nov 2023 05:07:55 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Kyq1cvBb; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2851a2b30a2so1826490a91.3; Fri, 24 Nov 2023 21:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700888874; x=1701493674; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PiMG3HJ6AT9/hOyCFeiiqx3YGFdYVOiuHe1S4Ni7stk=; b=Kyq1cvBb8zTggqdCy4pIlrJVH/S0I96fknFehSUUmIOoRy6gLAaGTI7nJZzUvKCbvu CVc3Ci1PdXWplI5QC7xnmtj9pAVW6FVNmD7V++XcSQN/6VMVtUAJP3XVZa++80iTwzxt pReh3aJ70Y+dHzen+3huyQKaFpQUmc+iJwXZ+r4NVnvYyJnUs3zJKhqdU7fQVzF998vg dkhAobcl5UXz8VXQ3X4OAAiIBkfAkd5cIs5r+acBF7QXbUwAWXaleWwxcXxGDunfbBaP 1VKJ1dBryfdtTsrthQQTNPMP0oq5vBhLJWfX8k5TxPaRcsMiNEk8ukXB9BujqFg7Br7F Hjuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700888874; x=1701493674; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PiMG3HJ6AT9/hOyCFeiiqx3YGFdYVOiuHe1S4Ni7stk=; b=mp1fOPEr06UCS3RXAtBwKDCfMa6erXoEO5HcfdUckOo4MoejCe2vAL7Ylc+q6hbay9 Xax0gAMK5dKmI65FzZv/RAZVuWNpPzeX7say4Hn31gBEu/WTt5ukZdMWV6O0uyHVdMkn /w8FLpPzltHAP4384LYCdt0EHaPhUXBokZBZjXSoLLIVsni51eu9U/4eY27axszL31eL DOLnW57AAfvyaqrZSl1PRjtJC4rgqxjwmIBl8mF1uF//qjV2DkIp9njqKAZUiERCHyNo 6Y94YVieha4iJlKUdgjn4CtasF2jy8BlkmMASBOZlep2h5yfB3vsc5nO+UocVQTnCHlR yqYw== X-Gm-Message-State: AOJu0YxvQfKvAoJosfSm4Q5fPsakNr0KK/OdCNySZJrNqH73yVB6pgp7 IYVTj4cqgpHqHJIE66AkPdaH1Qp1WbZV/KD7eQ== X-Google-Smtp-Source: AGHT+IHgLm72dd2uyTXJkINHm8muUEtT4iCik3NW9OrQZpL9PU8h7unViQV5JORro4rP2EIVSQHuFoN94vY1JOLeu90= X-Received: by 2002:a17:90b:3cb:b0:285:6211:6e1b with SMTP id go11-20020a17090b03cb00b0028562116e1bmr5439207pjb.28.1700888874115; Fri, 24 Nov 2023 21:07:54 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202311231525.3ANFPBo6039293@gitrepo.freebsd.org> <987d4593d50b9cbffb9b6443d3825499@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Fri, 24 Nov 2023 21:07:45 -0800 Message-ID: Subject: Re: git: f5f277728ade - main - nfsd: Fix NFS access to .zfs/snapshot snapshots To: Mike Karels Cc: Konstantin Belousov , Alexander Leidinger , Rick Macklem , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.82 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_SPAM_SHORT(0.17)[0.171]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,leidinger.net,freebsd.org] X-Rspamd-Queue-Id: 4ScfxR4YGJz4SZZ X-Spamd-Bar: -- Just to summarize... Mike Karels has done a simple test that works, so I don't know why my tests have misbehaved. I will do some more tests in a few weeks. If you encounter problems accessing snapshots under .zfs/snapshot over NFS when you have added the patch in PR#275200, please post. rick On Fri, Nov 24, 2023 at 6:52=E2=80=AFPM Rick Macklem wrote: > > On Fri, Nov 24, 2023 at 4:15=E2=80=AFPM Rick Macklem wrote: > > > > On Fri, Nov 24, 2023 at 3:35=E2=80=AFPM Rick Macklem wrote: > > > > > > On Fri, Nov 24, 2023 at 8:16=E2=80=AFAM Rick Macklem wrote: > > > > > > > > On Fri, Nov 24, 2023 at 7:58=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > On Fri, Nov 24, 2023 at 5:18=E2=80=AFAM Mike Karels wrote: > > > > > > > > > > > > CAUTION: This email originated from outside of the University o= f Guelph. Do not click links or open attachments unless you recognize the s= ender and know the content is safe. If in doubt, forward suspicious emails = to IThelp@uoguelph.ca. > > > > > > > > > > > > > > > > > > On 24 Nov 2023, at 7:02, Konstantin Belousov wrote: > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 08:50:22AM +0100, Alexander Leidinger= wrote: > > > > > > >> Am 2023-11-23 16:25, schrieb Rick Macklem: > > > > > > >>> The branch main has been updated by rmacklem: > > > > > > >>> > > > > > > >>> URL: https://cgit.FreeBSD.org/src/commit/?id=3Df5f277728ade= c4c5b3e840a1fb16bd16f8cc956d > > > > > > >>> > > > > > > >>> commit f5f277728adec4c5b3e840a1fb16bd16f8cc956d > > > > > > >>> Author: Rick Macklem > > > > > > >>> AuthorDate: 2023-11-23 15:23:33 +0000 > > > > > > >>> Commit: Rick Macklem > > > > > > >>> CommitDate: 2023-11-23 15:23:33 +0000 > > > > > > >>> > > > > > > >>> nfsd: Fix NFS access to .zfs/snapshot snapshots > > > > > > >>> > > > > > > >>> When a process attempts to access a snapshot under > > > > > > >>> //.zfs/snapshot, the snapshot is automounted. > > > > > > >>> However, without this patch, the automount does not > > > > > > >>> set mnt_exjail, which results in the snapshot not being > > > > > > >>> accessible over NFS. > > > > > > >>> > > > > > > >>> This patch defines a new function called vfs_exjail_clo= ne() > > > > > > >>> which sets mnt_exjail from another mount point and > > > > > > >>> then uses that function to set mnt_exjail in the snapsh= ot > > > > > > >>> automount. A separate patch that is currently a pull r= equest > > > > > > >>> for OpenZFS, calls this function to fix the problem. > > > > > > >> > > > > > > >> May the same/similar fix like for ZFS be needed / useful for= nullfs mounted > > > > > > >> stuff? > > > > > > >> > > > > > > >> I have a ZFS dataset which is mounted via nullfs into a jail= . This > > > > > > >> nullfs-mount is then exported via samba. In samba I have the= shadow-copy > > > > > > >> stuff enabled, but it doesn't work, as the jails can't acces= s the snapshot. > > > > > > > > > > > > > > Jails cannot access snapshots because, as I understand, snaps= hots > > > > > > > are mounts. Nullfs does not provide an option to recursively = bypass > > > > > > > into mounts. The patch you responded to does not automaticall= y mounts > > > > > > > snapshots on clients, it only allows them to mount if wanted. > > > > > > > > > > > > It works for me, with main and this change, or 13.2 without a p= atch. > > > > > > I don't know the mechanics, but it doesn't use nullfs, and the = snapshot > > > > > > does not show up as a separate filesystem with the mount comman= d. > > > > > Yes. ZFS essentially does an automount of the snapshots under .zf= s/snapshot. > > > > > (As I understand it, there are non-default ZFS options that allow= these to be > > > > > mounted manually instead.) > > > > > I can now see that these automounts are 'real mounts" in the > > > > > mountlist. The only reason > > > > > they are not visible is that they have MNT_IGNORE set on them. > > > > Oh and I forgot to mention that this automount is for some weird in > > > > memory file system that does just enough so you can see the snapsho= ts. > > > > Once you "cd ", the vnodes are associated with the Z= FS > > > > mount (dataset) and not this weird snapshot fs. (That is why it doe= sn't need to > > > > be exported, but did need mnt_exjail to be set properly.) > > > > > > > > I might be able to test a nullfs over ZFS case later to-day and wil= l > > > > post if I do so. > > > Yes, it is broken in a similar way. With a nullfs mount on top of a Z= FS mount > > > that is exported to an NFS client, you can access the snapshots under > > > .zfs/snapshot > > > if the mnt_exjail checks are commented out. > > > However, if the checks are done, they fail. > > > > > > So, yes, something similar to what ZFS will do is needed for nullfs. > > > Now I have to figure out how/when it can be done. I will play with it= to-day, > > > but it probably won't get fixed until late Dec. > > Oops. Now my test is not working, even when the mnt_exjail check is > > commented out. > > (When I NFS mount the ZFS , I can see the snapshots under > > .zfs/snapshot, > > but when I NFS mount the nullfs mount that is on top of the ZFS > > I do not see it. > > > > So, I think Kostik is correct and it does not see the .zfs/snapshot aut= omount. > > > > I don't know how I screwed up on the first test after I disabled the > > mnt_exjail check, but > > it does not appear to have broken this case after all. > More info. Thanks to some off-list info from Mike Karels I tried it again= . > It turns out that the nullfs on top of ZFS export (the nullfs mount must = be > exported) sorta works. When you cd .zfs/snapshot/, it > works. > > What doesn't work is: > cd .zfs/snapshot > ls > --> which does not show the snapshot names > The snapshot names are shown for a mount of the ZFS file system. > > So, it seems that the Readdir has issues for a nullfs on top of ZFS > export for the .zfs/snapshot directory. I will poke at it some more > in late Dec., but it does not seem to be a problem related to mnt_exjail. > > rick > > > > > rick > > > > > > > > Again, sorry for the breakage, rick > > > > > > > > > > > rick > > > > > > > > > > > > > > Now, as for what happens when nullfs is on top of ZFS, I do not k= now. > > > > > What Kostik says about nullfs recursing into mounts suggests it w= ill not work. > > > > > I will look at it, but since I am headed to Florida for a few wee= ks, it may > > > > > not happen until the end of the year. > > > > > > > > > > If someone can test this case and determine if there is no NFS cl= ient access > > > > > for snapshots under .zfs after applying the patch that is an > > > > > attachment in PR#275200 > > > > > when nullfs is over the ZFS file system, that would be appreciate= d. > > > > > > > > > > rick > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > You might try to set up something with autofs, no idea if it = could be made > > > > > > > to work usefully. > > > > > >