From nobody Fri Nov 24 15:58:58 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 4ScKRL68knz526YG; Fri, 24 Nov 2023 15:59:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 4ScKRL0vpMz3JVf; Fri, 24 Nov 2023 15:59:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-28397a2c402so1555216a91.2; Fri, 24 Nov 2023 07:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700841548; x=1701446348; 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=Uwfr0AV9sksOICNM+XXVqQmwLF+fRWEWC5S9+I9sHIM=; b=FjE2IkGITg/BVtDUcuMojiL42+yum2VQJn8Fk7c60XlKw4G55g0bsH2s6VLPfXBDEb YaUJgan8E4n0y6vXHr80ND7y35+hqDWmMMg3WWTFxkT950qfYShGjIyt4D6mdqmdXHda cWM6fsJYCdZaSWvqT8IjOFbIigQ4iCSbVXyLI8ugMUSWRyB42BkFqrm5iZCrzcPYpOhn SjHVZ9Jtd93D82JvhOPd6lRWDF9uwCe/BlqKZzRZ3/UEqmcCY8HxAiUsKf6Ta2Rkyv7Z lfFIlYhO0JyykH2Ji9kvegLBhwnxFcOv7JA7uR0xPQxBSSPDLeJv+A5bil1Sl7URo5ZM 8CPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700841548; x=1701446348; 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=Uwfr0AV9sksOICNM+XXVqQmwLF+fRWEWC5S9+I9sHIM=; b=VSUEDASZE9KY9rMYeZgS0CXf8OSHjxd8NlNmr0ihgi+OUaHe6VKZLWoT8Snto11r+W 9v30ZqgvYkcmz7Cd228pAqyWH7Ikm6dkloXFb/kMmwnU8CZUx7isRfOpGesOF9te6djd kVOwPztdnPF+fn9Kbkn2abUxSJmQi3rBGCRWnXFQRgywRfzarizwgwli95sefRwtsquf pg0eEBtTvf2DxbQ+23TKveXkqn8vTp2EAAg+ERcFFf3bPIvZaz1hXyknuK5NSwt+m4nh /jKchsuS1tni7LGQ5anwm5Wga6XF4X6buwdqs9MwUTGZNl5pB8dJnRwBQmtyL6XumD8L j1SQ== X-Gm-Message-State: AOJu0YygjhPD1yDYTDRebnQ1mqCuVDIphLo+le5Hsee+YYaiPSmHNFJh AkZvRm4sEyQSjnP1E7ghZBYYDAgjAU0EUBpn2Q== X-Google-Smtp-Source: AGHT+IHtwC20bf69CROIlHzqEVcrfy3RTtVOHGoMYu6L+ypDzFUrIIDczNPmy6O25fo+8pmISMf11yzKNTIlIf9Bxa4= X-Received: by 2002:a17:90a:de8e:b0:27d:dc9:c67d with SMTP id n14-20020a17090ade8e00b0027d0dc9c67dmr2986196pjv.36.1700841548448; Fri, 24 Nov 2023 07:59:08 -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 07:58:58 -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-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Queue-Id: 4ScKRL0vpMz3JVf On Fri, Nov 24, 2023 at 5:18=E2=80=AFAM Mike Karels wrote= : > > CAUTION: This email originated from outside of the University of Guelph. = Do not click links or open attachments unless you recognize the sender 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=3Df5f277728adec4c5b3e840= a1fb16bd16f8cc956d > >>> > >>> 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_clone() > >>> which sets mnt_exjail from another mount point and > >>> then uses that function to set mnt_exjail in the snapshot > >>> automount. A separate patch that is currently a pull request > >>> for OpenZFS, calls this function to fix the problem. > >> > >> May the same/similar fix like for ZFS be needed / useful for nullfs mo= unted > >> 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-co= py > >> stuff enabled, but it doesn't work, as the jails can't access the snap= shot. > > > > Jails cannot access snapshots because, as I understand, snapshots > > are mounts. Nullfs does not provide an option to recursively bypass > > into mounts. The patch you responded to does not automatically 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 patch. > 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 command. Yes. ZFS essentially does an automount of the snapshots under .zfs/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. Now, as for what happens when nullfs is on top of ZFS, I do not know. What Kostik says about nullfs recursing into mounts suggests it will not wo= rk. I will look at it, but since I am headed to Florida for a few weeks, it may not happen until the end of the year. If someone can test this case and determine if there is no NFS client acces= s 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 appreciated. rick > > Mike > > > You might try to set up something with autofs, no idea if it could be m= ade > > to work usefully. >