Re: NFS exports of ZFS snapshots broken
On 18 Nov 2023, at 21:19, Rick Macklem wrote: > On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote: >> >> On 18 Nov 2023, at 17:23, Rick Macklem wrote: >> >>> On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: On 18 Nov 2023, at 15:58, Rick Macklem wrote: > On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem > wrote: >> >> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: >>> >>> On 17 Nov 2023, at 22:14, Mike Karels wrote: >>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > Most of the changes in stable/13 that are not in releng/13.2 > are the "make it work in a jail" stuff. Unfortunately, they are > a large # of changes (mostly trivial edits adding vnet macros), > but it also includes export check changes. > > I have attached a trivial patch that I think disables the export > checks for jails. If either of you can try it and see if it fixes > the problem, that would be great. > (Note that this is only for testing, although it probably does not > matter unless you are running nfsd(8) in vnet jails.) Yes, I can see snapshots with the patch. This system is just a test system that doesn't normally run ZFS or NFS, so no problem messing with permissions. It's a bhyve VM, so I just added a small disk and enabled ZFS for testing. >>> >>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS >>> side. It must be doing something differently inside a snapshot than >>> outside, maybe with file handles or something like that. >> Yes. I've added freebsd-current@ (although Garrett is not on it, he is >> cc'd) and these guys specifically... >> >> So, here's what appears to be the problem... >> Commit 88175af (in main and stable/13, but not 13.2) added checks for >> nfsd(8) running in jails by filling in mnt_exjail with a reference to >> the cred >> used when the file system is exported. >> When mnt_exjail is found NULL, the current nfsd code assumes that there >> is no access allowed for the mount. >> >> My vague understanding is that when a ZFS snapshot is accessed, it is >> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that >> mnt_exjail is NULL as a result. >> Since I do not know the ZFS code and don't even have an easy way to >> test this (thankfully Mike can test easily), I do not know what to do >> from >> here? >> >> Is there a "struct mount" constructed for this pseudo mount >> (or it actually appears to be the lookup of ".." that fails, so it >> might be the parent of the snapshot subdir?)? >> >> One thought is that I can check to see if the mount pointer is in the >> mountlist (I don't think the snapshot's mount is in the mountlist) and >> avoid the jail test for this case. This would assume that snapshots are >> always within the file system(s) exported via that jail (which includes >> the case of prison0, of course), so that they do not need a separate >> jail check. >> >> If this doesn't work, there will need to be some sort of messing about >> in ZFS to set mnt_exjail for these. > Ok, so now onto the hard part... > Thanks to Mike and others, I did create a snapshot under .zfs and I can > see the problem. It is that mnt_exjail == NULL. > Now, is there a way that this "struct mount" can be recognized as > "special" > for snapshots, so I can avoid the mnt_exjail == NULL test? > (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not > the case.) Dumb question, is the mount point (mp presumably) different between the snapshot and the main file system? >>> Not a dump question and the answer is rather interesting... >>> It is "sometimes" or "usually" according to my printf(). >>> It seems that when you first "cd >> where mnt_exjail == NULL.. Then when you look at directories within the >>> snapshot, you get the mp of the file system that .zfs exists in, which does >>> have mnt_exjail set non-NULL. >>> >>> There is this snippet of code in zfsctl_snapdir_lookup(): >>> /* >>> * Fix up the root vnode mounted on .zfs/snapshot/. >>> * >>> * This is where we lie about our v_vfsp in order to >>> * make .zfs/snapshot/ accessible over NFS >>> * without requiring manual mounts of . >>> */ >>> ASSERT3P(VTOZ(*vpp)->z_zfsvfs, !=, zfsvfs); >>> VTOZ(*vpp)->z_zfsvfs->z_parent = zfsvfs; >>> >>> /* Clear the root flag (set via VFS_ROOT) as well. */ >>> (*vpp)->v_vflag &= ~VV_ROOT; >>> which seems to set the mp to that of the parent, but it >>> seems this does not happen for the initial lookup of >>> the ? >>> >>> I'll note that there is code before this in >>> zfsctl_snapdir_lookup() for handling cases >>> like "." and ".." that return without doing this. >>> >>> Now, why does this work without the mnt_exj
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote: > > On 18 Nov 2023, at 17:23, Rick Macklem wrote: > > > On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: > >> > >> On 18 Nov 2023, at 15:58, Rick Macklem wrote: > >> > >>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem > >>> wrote: > > On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > > > > On 17 Nov 2023, at 22:14, Mike Karels wrote: > > > >> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > >> > >>> Most of the changes in stable/13 that are not in releng/13.2 > >>> are the "make it work in a jail" stuff. Unfortunately, they are > >>> a large # of changes (mostly trivial edits adding vnet macros), > >>> but it also includes export check changes. > >>> > >>> I have attached a trivial patch that I think disables the export > >>> checks for jails. If either of you can try it and see if it fixes > >>> the problem, that would be great. > >>> (Note that this is only for testing, although it probably does not > >>> matter unless you are running nfsd(8) in vnet jails.) > >> > >> Yes, I can see snapshots with the patch. This system is just a test > >> system that doesn't normally run ZFS or NFS, so no problem messing > >> with permissions. It's a bhyve VM, so I just added a small disk and > >> enabled ZFS for testing. > > > > btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > > side. It must be doing something differently inside a snapshot than > > outside, maybe with file handles or something like that. > Yes. I've added freebsd-current@ (although Garrett is not on it, he is > cc'd) and these guys specifically... > > So, here's what appears to be the problem... > Commit 88175af (in main and stable/13, but not 13.2) added checks for > nfsd(8) running in jails by filling in mnt_exjail with a reference to > the cred > used when the file system is exported. > When mnt_exjail is found NULL, the current nfsd code assumes that there > is no access allowed for the mount. > > My vague understanding is that when a ZFS snapshot is accessed, it is > "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > mnt_exjail is NULL as a result. > Since I do not know the ZFS code and don't even have an easy way to > test this (thankfully Mike can test easily), I do not know what to do > from > here? > > Is there a "struct mount" constructed for this pseudo mount > (or it actually appears to be the lookup of ".." that fails, so it > might be the parent of the snapshot subdir?)? > > One thought is that I can check to see if the mount pointer is in the > mountlist (I don't think the snapshot's mount is in the mountlist) and > avoid the jail test for this case. This would assume that snapshots are > always within the file system(s) exported via that jail (which includes > the case of prison0, of course), so that they do not need a separate > jail check. > > If this doesn't work, there will need to be some sort of messing about > in ZFS to set mnt_exjail for these. > >>> Ok, so now onto the hard part... > >>> Thanks to Mike and others, I did create a snapshot under .zfs and I can > >>> see the problem. It is that mnt_exjail == NULL. > >>> Now, is there a way that this "struct mount" can be recognized as > >>> "special" > >>> for snapshots, so I can avoid the mnt_exjail == NULL test? > >>> (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not > >>> the case.) > >> > >> Dumb question, is the mount point (mp presumably) different between the > >> snapshot and the main file system? > > Not a dump question and the answer is rather interesting... > > It is "sometimes" or "usually" according to my printf(). > > It seems that when you first "cd > where mnt_exjail == NULL.. Then when you look at directories within the > > snapshot, you get the mp of the file system that .zfs exists in, which does > > have mnt_exjail set non-NULL. > > > > There is this snippet of code in zfsctl_snapdir_lookup(): > > /* > > * Fix up the root vnode mounted on .zfs/snapshot/. > > * > > * This is where we lie about our v_vfsp in order to > > * make .zfs/snapshot/ accessible over NFS > > * without requiring manual mounts of . > > */ > > ASSERT3P(VTOZ(*vpp)->z_zfsvfs, !=, zfsvfs); > > VTOZ(*vpp)->z_zfsvfs->z_parent = zfsvfs; > > > > /* Clear the root flag (set via VFS_ROOT) as well. */ > > (*vpp)->v_vflag &= ~VV_ROOT; > > which seems to set the mp to that of the parent, but it > > seems this does not happen for the initial lookup of > > the ? > > > > I'll note that there is code before this in > > zfsctl_snapdir_lookup() for handling cases > > like "." and ".." that return without doing this. > > > > Now, why does this work without the mnt_exjail > > check (as in 13.2)? > > I am not quite sure,
Re: Update to the Release Engineering Team Roster
On Fri, 17 Nov 2023 23:52:40 + Glen Barber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > FreeBSD community, > > It is with a heavy heart that I have decided to resign my role as the > Release Engineering Team Lead. > > Colin Percival will take over this role, and I will act as his Deputy > Lead unless and until he finds a more suitable person to fill this > role. > > Regardless, I do not have any immediate plans to resign from the RE > Team as a whole, and though Colin has proved during the 13.2-RELEASE > cycle that he is fully capable of overtaking this role, I will remain > active on the team and will be available to him to provide any > guidance or insights as needed. > > I personally want to thank Colin for accepting this role change. I > have worked with Colin for several years directly, and indirectly, > much longer than I can remember. > > As I am sure many of you all are aware, Colin served the Project as > the Security Officer for several years, and authored important > utilities used by many within the community, such as portsnap and > freebsd-update. > > I have sent and received acknowledgement from the Core Team of this > decision to step aside, which was well received and no objection to me > selecting Colin to be my successor had been posed. > > Colin, thank you, again, for overtaking this role, and as we > discussed, I will be here to provide any needed guidance, insight, or > information as you need. As I had mentioned to you, I do not have > any immediate plans to leave the Team, nor do I have any question in > my mind that you are the obvious successor to this role. > > I am proud to be able to hand over the proverbial torch to you, and > look very much forward to your successes as the Release Engineering > Team Lead. > > It has been an absolute pleasure to be able to serve you all to the > best of my abilities over the past several years. > > With my very best regards to all involved in the Project, and nothing > but the best intentions of the Project in mind. > > Glen > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmVX/MgACgkQAxRYpUeP > 4pPLVg/9HW6nhw6EXTGqkrdibCkThurdasCqftkLSGrsABDj1AsErHbBnbO3W04G > KSVZ6Jw28JQNGUsprJwcAsJre8PXgL2iKOkIZTL31CYSBvQbfGEzIWTC+18oTQ6Q > d1uxqGcqoMcpPfFxSry8wnfxO7hYGabv38lPy2KipskCqq/3zVqsdVb6UxGdo+5Q > 0sis6OVh8KhNdcgOu+RTZr194KJogsdqqGll4pOQNMv/Qpy5e9JOqHgVXueseUC8 > 6GDHa990VLF22+DLgq3qzVS0xGLIOM5MuC0EjWJEjaq5bANEzQX0SvMEKQEbGLrI > MjBXGoJGTreBMr0VbCewhuDIiYy7DU5dtohvXvCx+UoBryT9qU1RKmRyRxxp3hQ4 > dcZUyZ3RarwmZfJBTs7ib2s9LztUlpyIRAU7gJ2vRKcegVTH/Fe1FuRZHOFHZf46 > kzHeIygER3nitPtJj9ePQgq97F2WBjRDZ5MSzwNWsOMknsbUKekIB9xshbhxlUw8 > 5ZN61k3frKM/dOcnLulsNHFaMGJaodDsxMuTKhJCEHvHWLXOin66WrfuHKbeqzVf > LDgMCWiHcM0GwrtzXR/aITVZmwyg096gZw0NLXtlNadY+PyQrg8R83DmOKTk0fWo > MYaMnWBcZM78DviTaBPhcblMtB5/IqrbJzqnJqsnCBEW2Z29qgs= > =sYrP > -END PGP SIGNATURE- > Hi Glen I find myself at a time where I could possibly lend a hand, would someone like me be able to help with r...@freebsd.org? Teach and I can learn I guess ... I tend to excel but totally unsure if I can fit the bill! Regards Matti
Re: NFS exports of ZFS snapshots broken
On 18 Nov 2023, at 17:23, Rick Macklem wrote: > On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: >> >> On 18 Nov 2023, at 15:58, Rick Macklem wrote: >> >>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote: On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > > On 17 Nov 2023, at 22:14, Mike Karels wrote: > >> On 17 Nov 2023, at 21:24, Rick Macklem wrote: >> >>> Most of the changes in stable/13 that are not in releng/13.2 >>> are the "make it work in a jail" stuff. Unfortunately, they are >>> a large # of changes (mostly trivial edits adding vnet macros), >>> but it also includes export check changes. >>> >>> I have attached a trivial patch that I think disables the export >>> checks for jails. If either of you can try it and see if it fixes >>> the problem, that would be great. >>> (Note that this is only for testing, although it probably does not >>> matter unless you are running nfsd(8) in vnet jails.) >> >> Yes, I can see snapshots with the patch. This system is just a test >> system that doesn't normally run ZFS or NFS, so no problem messing >> with permissions. It's a bhyve VM, so I just added a small disk and >> enabled ZFS for testing. > > btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > side. It must be doing something differently inside a snapshot than > outside, maybe with file handles or something like that. Yes. I've added freebsd-current@ (although Garrett is not on it, he is cc'd) and these guys specifically... So, here's what appears to be the problem... Commit 88175af (in main and stable/13, but not 13.2) added checks for nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred used when the file system is exported. When mnt_exjail is found NULL, the current nfsd code assumes that there is no access allowed for the mount. My vague understanding is that when a ZFS snapshot is accessed, it is "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that mnt_exjail is NULL as a result. Since I do not know the ZFS code and don't even have an easy way to test this (thankfully Mike can test easily), I do not know what to do from here? Is there a "struct mount" constructed for this pseudo mount (or it actually appears to be the lookup of ".." that fails, so it might be the parent of the snapshot subdir?)? One thought is that I can check to see if the mount pointer is in the mountlist (I don't think the snapshot's mount is in the mountlist) and avoid the jail test for this case. This would assume that snapshots are always within the file system(s) exported via that jail (which includes the case of prison0, of course), so that they do not need a separate jail check. If this doesn't work, there will need to be some sort of messing about in ZFS to set mnt_exjail for these. >>> Ok, so now onto the hard part... >>> Thanks to Mike and others, I did create a snapshot under .zfs and I can >>> see the problem. It is that mnt_exjail == NULL. >>> Now, is there a way that this "struct mount" can be recognized as "special" >>> for snapshots, so I can avoid the mnt_exjail == NULL test? >>> (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not >>> the case.) >> >> Dumb question, is the mount point (mp presumably) different between the >> snapshot and the main file system? > Not a dump question and the answer is rather interesting... > It is "sometimes" or "usually" according to my printf(). > It seems that when you first "cd where mnt_exjail == NULL.. Then when you look at directories within the > snapshot, you get the mp of the file system that .zfs exists in, which does > have mnt_exjail set non-NULL. > > There is this snippet of code in zfsctl_snapdir_lookup(): > /* > * Fix up the root vnode mounted on .zfs/snapshot/. > * > * This is where we lie about our v_vfsp in order to > * make .zfs/snapshot/ accessible over NFS > * without requiring manual mounts of . > */ > ASSERT3P(VTOZ(*vpp)->z_zfsvfs, !=, zfsvfs); > VTOZ(*vpp)->z_zfsvfs->z_parent = zfsvfs; > > /* Clear the root flag (set via VFS_ROOT) as well. */ > (*vpp)->v_vflag &= ~VV_ROOT; > which seems to set the mp to that of the parent, but it > seems this does not happen for the initial lookup of > the ? > > I'll note that there is code before this in > zfsctl_snapdir_lookup() for handling cases > like "." and ".." that return without doing this. > > Now, why does this work without the mnt_exjail > check (as in 13.2)? > I am not quite sure, but there is this "cheat" in the > NFS server (it has been there for years, maybe decades): > /* > * Allow a Lookup, Getattr, GetFH, Secinfo on an > * non-exported directory if > * nfs_rootfhset. Do I need to allow any other Ops? > * (You can only have a non-e
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote:
>
> On 18 Nov 2023, at 15:58, Rick Macklem wrote:
>
> > On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote:
> >>
> >> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote:
> >>>
> >>> On 17 Nov 2023, at 22:14, Mike Karels wrote:
> >>>
> On 17 Nov 2023, at 21:24, Rick Macklem wrote:
>
> > Most of the changes in stable/13 that are not in releng/13.2
> > are the "make it work in a jail" stuff. Unfortunately, they are
> > a large # of changes (mostly trivial edits adding vnet macros),
> > but it also includes export check changes.
> >
> > I have attached a trivial patch that I think disables the export
> > checks for jails. If either of you can try it and see if it fixes
> > the problem, that would be great.
> > (Note that this is only for testing, although it probably does not
> > matter unless you are running nfsd(8) in vnet jails.)
>
> Yes, I can see snapshots with the patch. This system is just a test
> system that doesn't normally run ZFS or NFS, so no problem messing
> with permissions. It's a bhyve VM, so I just added a small disk and
> enabled ZFS for testing.
> >>>
> >>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS
> >>> side. It must be doing something differently inside a snapshot than
> >>> outside, maybe with file handles or something like that.
> >> Yes. I've added freebsd-current@ (although Garrett is not on it, he is
> >> cc'd) and these guys specifically...
> >>
> >> So, here's what appears to be the problem...
> >> Commit 88175af (in main and stable/13, but not 13.2) added checks for
> >> nfsd(8) running in jails by filling in mnt_exjail with a reference to the
> >> cred
> >> used when the file system is exported.
> >> When mnt_exjail is found NULL, the current nfsd code assumes that there
> >> is no access allowed for the mount.
> >>
> >> My vague understanding is that when a ZFS snapshot is accessed, it is
> >> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that
> >> mnt_exjail is NULL as a result.
> >> Since I do not know the ZFS code and don't even have an easy way to
> >> test this (thankfully Mike can test easily), I do not know what to do from
> >> here?
> >>
> >> Is there a "struct mount" constructed for this pseudo mount
> >> (or it actually appears to be the lookup of ".." that fails, so it
> >> might be the parent of the snapshot subdir?)?
> >>
> >> One thought is that I can check to see if the mount pointer is in the
> >> mountlist (I don't think the snapshot's mount is in the mountlist) and
> >> avoid the jail test for this case. This would assume that snapshots are
> >> always within the file system(s) exported via that jail (which includes
> >> the case of prison0, of course), so that they do not need a separate
> >> jail check.
> >>
> >> If this doesn't work, there will need to be some sort of messing about
> >> in ZFS to set mnt_exjail for these.
> > Ok, so now onto the hard part...
> > Thanks to Mike and others, I did create a snapshot under .zfs and I can
> > see the problem. It is that mnt_exjail == NULL.
> > Now, is there a way that this "struct mount" can be recognized as "special"
> > for snapshots, so I can avoid the mnt_exjail == NULL test?
> > (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not
> > the case.)
>
> Dumb question, is the mount point (mp presumably) different between the
> snapshot and the main file system?
Not a dump question and the answer is rather interesting...
It is "sometimes" or "usually" according to my printf().
It seems that when you first "cd .
*
* This is where we lie about our v_vfsp in order to
* make .zfs/snapshot/ accessible over NFS
* without requiring manual mounts of .
*/
ASSERT3P(VTOZ(*vpp)->z_zfsvfs, !=, zfsvfs);
VTOZ(*vpp)->z_zfsvfs->z_parent = zfsvfs;
/* Clear the root flag (set via VFS_ROOT) as well. */
(*vpp)->v_vflag &= ~VV_ROOT;
which seems to set the mp to that of the parent, but it
seems this does not happen for the initial lookup of
the ?
I'll note that there is code before this in
zfsctl_snapdir_lookup() for handling cases
like "." and ".." that return without doing this.
Now, why does this work without the mnt_exjail
check (as in 13.2)?
I am not quite sure, but there is this "cheat" in the
NFS server (it has been there for years, maybe decades):
/*
* Allow a Lookup, Getattr, GetFH, Secinfo on an
* non-exported directory if
* nfs_rootfhset. Do I need to allow any other Ops?
* (You can only have a non-exported vpnes if
* nfs_rootfhset is true. See nfsd_fhtovp())
* Allow AUTH_SYS to be used for file systems
* exported GSS only for certain Ops, to allow
* clients to do mounts more easily.
*/
if (nfsv4_opflag[op].needscfh && vp) {
if (!NFSVNO_EXPORTED(&vpnes) &&
op != NFSV4OP_LOOKUP &&
op != NFSV4OP_GETATTR &&
op != NFSV4OP_GETFH &&
op != NFSV4OP_ACCESS &&
op !=
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 10:47 AM Ronald Klop 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 > ith...@uoguelph.ca. > > > On 11/18/23 17:09, Rick Macklem wrote: > > On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > >> > >> On 17 Nov 2023, at 22:14, Mike Karels wrote: > >> > >>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > >>> > Most of the changes in stable/13 that are not in releng/13.2 > are the "make it work in a jail" stuff. Unfortunately, they are > a large # of changes (mostly trivial edits adding vnet macros), > but it also includes export check changes. > > I have attached a trivial patch that I think disables the export > checks for jails. If either of you can try it and see if it fixes > the problem, that would be great. > (Note that this is only for testing, although it probably does not > matter unless you are running nfsd(8) in vnet jails.) > >>> > >>> Yes, I can see snapshots with the patch. This system is just a test > >>> system that doesn't normally run ZFS or NFS, so no problem messing > >>> with permissions. It's a bhyve VM, so I just added a small disk and > >>> enabled ZFS for testing. > >> > >> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > >> side. It must be doing something differently inside a snapshot than > >> outside, maybe with file handles or something like that. > > Yes. I've added freebsd-current@ (although Garrett is not on it, he is > > cc'd) and these guys specifically... > > > > So, here's what appears to be the problem... > > Commit 88175af (in main and stable/13, but not 13.2) added checks for > > nfsd(8) running in jails by filling in mnt_exjail with a reference to the > > cred > > used when the file system is exported. > > When mnt_exjail is found NULL, the current nfsd code assumes that there > > is no access allowed for the mount. > > > > My vague understanding is that when a ZFS snapshot is accessed, it is > > "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > > mnt_exjail is NULL as a result. > > Since I do not know the ZFS code and don't even have an easy way to > > test this (thankfully Mike can test easily), I do not know what to do from > > here? > > > > Is there a "struct mount" constructed for this pseudo mount > > (or it actually appears to be the lookup of ".." that fails, so it > > might be the parent of the snapshot subdir?)? > > > > One thought is that I can check to see if the mount pointer is in the > > mountlist (I don't think the snapshot's mount is in the mountlist) and > > avoid the jail test for this case. This would assume that snapshots are > > always within the file system(s) exported via that jail (which includes > > the case of prison0, of course), so that they do not need a separate > > jail check. > > > > If this doesn't work, there will need to be some sort of messing about > > in ZFS to set mnt_exjail for these. > > > > I will try and get a test setup going here, which leads me to.. > > how do I create a ZFS snapshot? (I do have a simple ZFS pool running > > on a test machine, but I've never done a snapshot.) > > # zfs list > ... > zroot/usr/local4.59G 27.5G 2.76G /usr/local > zroot/usr/ports1.03G 27.5G 952M /usr/ports > ... > > # zfs snapshot zroot/usr/local@myfirstsnapshot > -- to view them > # zfs list -t snapshot zroot/usr/local > -- and to remove it: > # zfs destroy zroot/usr/local@myfirstsnapshot > -- more info > # man zfs-snapshot > > If you get used to this you are going to love it. :-) Not likely. My test systems are old laptops and don't need fancy storage. However, I do have one very simple setup for testing. To give you a clue, it's called /example because the description I found to do it used "example" and I didn't even realize it would end up as the name of the mount. However, thanks to Mike and others, I do now have a snapshot on it. Now, as noted in my other post, comes the hard part. I hope I can identify that the "mount is special and refers to a snapshot" from the *mp, so I can avoid the mp->mnt_exjail == NULL check for this case. I'd like to avoid having to get ZFS set mnt_exjail for the snapshots. Thanks, rick > > Regards and happy hacking, > Ronald. > > > > > > Although this problem is not in 13.2, it will have shipped in 14.0. > > > > Any help with be appreciated, rick > > > >> > >> Mike > >>> > rick > > On Fri, Nov 17, 2023 at 6:14 PM 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 ith...@uoguelph.ca. >
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote: > > On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > > > > On 17 Nov 2023, at 22:14, Mike Karels wrote: > > > > > On 17 Nov 2023, at 21:24, Rick Macklem wrote: > > > > > >> Most of the changes in stable/13 that are not in releng/13.2 > > >> are the "make it work in a jail" stuff. Unfortunately, they are > > >> a large # of changes (mostly trivial edits adding vnet macros), > > >> but it also includes export check changes. > > >> > > >> I have attached a trivial patch that I think disables the export > > >> checks for jails. If either of you can try it and see if it fixes > > >> the problem, that would be great. > > >> (Note that this is only for testing, although it probably does not > > >> matter unless you are running nfsd(8) in vnet jails.) > > > > > > Yes, I can see snapshots with the patch. This system is just a test > > > system that doesn't normally run ZFS or NFS, so no problem messing > > > with permissions. It's a bhyve VM, so I just added a small disk and > > > enabled ZFS for testing. > > > > btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > > side. It must be doing something differently inside a snapshot than > > outside, maybe with file handles or something like that. > Yes. I've added freebsd-current@ (although Garrett is not on it, he is > cc'd) and these guys specifically... > > So, here's what appears to be the problem... > Commit 88175af (in main and stable/13, but not 13.2) added checks for > nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred > used when the file system is exported. > When mnt_exjail is found NULL, the current nfsd code assumes that there > is no access allowed for the mount. > > My vague understanding is that when a ZFS snapshot is accessed, it is > "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > mnt_exjail is NULL as a result. > Since I do not know the ZFS code and don't even have an easy way to > test this (thankfully Mike can test easily), I do not know what to do from > here? > > Is there a "struct mount" constructed for this pseudo mount > (or it actually appears to be the lookup of ".." that fails, so it > might be the parent of the snapshot subdir?)? > > One thought is that I can check to see if the mount pointer is in the > mountlist (I don't think the snapshot's mount is in the mountlist) and > avoid the jail test for this case. This would assume that snapshots are > always within the file system(s) exported via that jail (which includes > the case of prison0, of course), so that they do not need a separate > jail check. > > If this doesn't work, there will need to be some sort of messing about > in ZFS to set mnt_exjail for these. Ok, so now onto the hard part... Thanks to Mike and others, I did create a snapshot under .zfs and I can see the problem. It is that mnt_exjail == NULL. Now, is there a way that this "struct mount" can be recognized as "special" for snapshots, so I can avoid the mnt_exjail == NULL test? (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not the case.) Do I need to search mountlist for it? rick ps: The hack patch attached should fix the problem, but can only be safely used if mountd/nfsd are not run in any jails. > > I will try and get a test setup going here, which leads me to.. > how do I create a ZFS snapshot? (I do have a simple ZFS pool running > on a test machine, but I've never done a snapshot.) > > Although this problem is not in 13.2, it will have shipped in 14.0. > > Any help with be appreciated, rick > > > > > Mike > > > > > >> rick > > >> > > >> On Fri, Nov 17, 2023 at 6:14 PM 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 ith...@uoguelph.ca. > > >>> > > >>> > > >>> Rick, have you been following this thread on freebsd-stable? I have > > >>> been able > > >>> to reproduce this using a 13-stable server from Oct 7 and a 15-current > > >>> system > > >>> that is up to date using NFSv3. I did not reproduce with a 13.2 > > >>> server. The > > >>> client was running 13.2. Any ideas? A full bisect seems fairly > > >>> painful, but > > >>> maybe you have an idea of points to try. Fortunately, these are all > > >>> test > > >>> systems that I can reboot at will. > > >>> > > >>> Mike > > >>> > > >>> Forwarded message: > > >>> > > From: Garrett Wollman > > To: Mike Karels > > Cc: freebsd-sta...@freebsd.org > > Subject: Re: NFS exports of ZFS snapshots broken > > Date: Fri, 17 Nov 2023 17:35:04 -0500 > > > > < > > said: > > > > > I have not run into this, so I tried it just now. I had no problem. > > > The server is 13.2, fully patched, the client is
Re: Request for Testing: TCP RACK
> On Nov 19, 2023, at 2:35 AM, Zhenlei Huang wrote: > > > >> On Nov 16, 2023, at 5:13 PM, tue...@freebsd.org wrote: >> >> Dear all, >> >> recently the main branch was changed to build the TCP RACK stack >> which is a loadable kernel module, by default: >> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc >> >> As discussed on the bi-weekly transport call, it would be great if people >> could test the RACK stack for their workload. Please report any problems to >> the >> net@ mailing list or open an issue in the bug tracker and drop me a note via >> email. >> This includes regressions in CPU usage, regressions in performance or any >> other >> unexpected change you observe. > > I see some performance regression with the rack stack. > > This is iperf3 test on local host (bare metal, an old i5 2 cores 4 threads > MBP). > > freebsd: 16.1 Gbits/sec > rack: 12.3 Gbits/sec > > The congestion control algorithm is cubic. > > Note this is a quick test with DEBUG options enabled. > > I'll try with no debug options and report later. ** UPDATE ** With no debug options: freebsd:37.2 Gbits/sec rack: 27.9 Gbits/sec > >> >> You can load the kernel module using >> kldload tcp_rack >> >> You can make the RACK stack the default stack using >> sysctl net.inet.tcp.functions_default=rack >> >> Based on the feedback we get, the default stack might be switched to the >> RACK stack. >> >> Please let me know if you have any questions. >> >> Best regards >> Michael >> >> >> > > Best regards, > Zhenlei
Re: Request for Testing: TCP RACK
On Sat, 18 Nov 2023 09:50:43 +0100 tue...@freebsd.org wrote: > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote: > > > > On Fri, 17 Nov 2023 18:51:05 +0100 > > tue...@freebsd.org wrote: > > > >>> On Nov 17, 2023, at 17:06, Johan Hendriks wrote: > >>> > >>> I am running the rack stack for quiet some time now on a baremetal > >>> machiene and never had problems. > >>> Also use pf. This is a test machine so not a lot happening on it. > >>> > >>> Are there any thing we can test? Do we have some test scripts we can run? > >> We are actually interested in feedback about using the stack in whatever > >> use case you use TCP for. The stack has been tested with the Netflix use > >> case, but not so much with others. That is why we ask for broader testing. > >> > >> Best regards > >> Michael > > > > Are there any difference regarding with performance between main and > > stable/14? If so, please ignore below. > > > > I have stable/14 environment which is configured to be able to switch > > to TCP RACK and experienced huge performance loss when writing > > a large file to smbfs share on commercial NAS. CC is cubic. > > Testing large archive on the smbfs share doesn't seem to be > > affected. > > > > Comparison between default (freebsd) and rack TCP stack using > > sysutils/clone on stable/14 at commit 7d1321288ad9, amd64. > > Last 3 lines of outputs from clone (upload to NAS) are shown. > Thank you very much for testing. This is what we are looking > for. Would it be possible to repeat the test using NewReno as > the CC? > > Best regards > Michael Sure. Here we go! sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: freebsd sysctl net.inet.tcp.cc.algorithm net.inet.tcp.cc.algorithm: newreno Umounted and remounted smbfs share. 1 item copied, 2343.1 MB in 37.65 s -- 62.2 MB/s Leaked memory: 0 bytes No errors occured. sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: rack Umounted and remounted smbfs share. 1 item copied, 2343.1 MB in 905.17 s -- 2.6 MB/s Leaked memory: 0 bytes No errors occured. sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: freebsd Without umount and remount to reproduce previous oddness, maybe caused by keep-alive. 1 item copied, 2343.1 MB in 897.67 s -- 2.6 MB/s Leaked memory: 0 bytes No errors occured. Umounted and remounted, without change for CC and TCP stack. 1 item copied, 2343.1 MB in 37.43 s -- 62.6 MB/s Leaked memory: 0 bytes No errors occured. All test are proceeded simultaneously. So the last one is with CC=newreno and TCP stack=freebsd. Not exactly recorded, but testing transferred file by diff -u -p -N was roughly 30MB/sec, while roughly 25MB/sec with CC=cubic. > > > > Before switching to rack: > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > Unmount the smbfs share, switch to rack, and after remount: > > 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > Switch back to freebsd (default) without unmounting: > > 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > Unmount and remount the smbfs share: > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > > > Regards. > > > > -- > > Tomoaki AOKI -- Tomoaki AOKI
Re: NFS exports of ZFS snapshots broken
On 11/18/23 17:09, Rick Macklem wrote: On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: On 17 Nov 2023, at 22:14, Mike Karels wrote: On 17 Nov 2023, at 21:24, Rick Macklem wrote: Most of the changes in stable/13 that are not in releng/13.2 are the "make it work in a jail" stuff. Unfortunately, they are a large # of changes (mostly trivial edits adding vnet macros), but it also includes export check changes. I have attached a trivial patch that I think disables the export checks for jails. If either of you can try it and see if it fixes the problem, that would be great. (Note that this is only for testing, although it probably does not matter unless you are running nfsd(8) in vnet jails.) Yes, I can see snapshots with the patch. This system is just a test system that doesn't normally run ZFS or NFS, so no problem messing with permissions. It's a bhyve VM, so I just added a small disk and enabled ZFS for testing. btw, you might try to get mm@ or maybe mav@ to help out from the ZFS side. It must be doing something differently inside a snapshot than outside, maybe with file handles or something like that. Yes. I've added freebsd-current@ (although Garrett is not on it, he is cc'd) and these guys specifically... So, here's what appears to be the problem... Commit 88175af (in main and stable/13, but not 13.2) added checks for nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred used when the file system is exported. When mnt_exjail is found NULL, the current nfsd code assumes that there is no access allowed for the mount. My vague understanding is that when a ZFS snapshot is accessed, it is "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that mnt_exjail is NULL as a result. Since I do not know the ZFS code and don't even have an easy way to test this (thankfully Mike can test easily), I do not know what to do from here? Is there a "struct mount" constructed for this pseudo mount (or it actually appears to be the lookup of ".." that fails, so it might be the parent of the snapshot subdir?)? One thought is that I can check to see if the mount pointer is in the mountlist (I don't think the snapshot's mount is in the mountlist) and avoid the jail test for this case. This would assume that snapshots are always within the file system(s) exported via that jail (which includes the case of prison0, of course), so that they do not need a separate jail check. If this doesn't work, there will need to be some sort of messing about in ZFS to set mnt_exjail for these. I will try and get a test setup going here, which leads me to.. how do I create a ZFS snapshot? (I do have a simple ZFS pool running on a test machine, but I've never done a snapshot.) # zfs list ... zroot/usr/local4.59G 27.5G 2.76G /usr/local zroot/usr/ports1.03G 27.5G 952M /usr/ports ... # zfs snapshot zroot/usr/local@myfirstsnapshot -- to view them # zfs list -t snapshot zroot/usr/local -- and to remove it: # zfs destroy zroot/usr/local@myfirstsnapshot -- more info # man zfs-snapshot If you get used to this you are going to love it. :-) Regards and happy hacking, Ronald. Although this problem is not in 13.2, it will have shipped in 14.0. Any help with be appreciated, rick Mike rick On Fri, Nov 17, 2023 at 6:14 PM 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 ith...@uoguelph.ca. Rick, have you been following this thread on freebsd-stable? I have been able to reproduce this using a 13-stable server from Oct 7 and a 15-current system that is up to date using NFSv3. I did not reproduce with a 13.2 server. The client was running 13.2. Any ideas? A full bisect seems fairly painful, but maybe you have an idea of points to try. Fortunately, these are all test systems that I can reboot at will. Mike Forwarded message: From: Garrett Wollman To: Mike Karels Cc: freebsd-sta...@freebsd.org Subject: Re: NFS exports of ZFS snapshots broken Date: Fri, 17 Nov 2023 17:35:04 -0500 < said: I have not run into this, so I tried it just now. I had no problem. The server is 13.2, fully patched, the client is up-to-date -current, and the mount is v4. On my 13.2 client and 13-stable server, I see: 25034 ls CALL open(0x237d32f9a000,0x120004) 25034 ls NAMI "/mnt/tools/.zfs/snapshot/weekly-2023-45" 25034 ls RET open 4 25034 ls CALL fcntl(0x4,F_ISUNIONSTACK,0x0) 25034 ls RET fcntl 0 25034 ls CALL getdirentries(0x4,0x237d32faa000,0x1000,0x237d32fa7028) 25034 ls RET getdirentries -1 errno 5 Input/output error 25034 ls CALL close(0x4) 25034 ls RET close 0 25034 ls CALL exit(0) Certainly a libc bug here that
Re: NFS exports of ZFS snapshots broken
Rick Macklem wrote on Date: Sat, 18 Nov 2023 16:09:34 UTC: > . . . > I will try and get a test setup going here, which leads me to.. > how do I create a ZFS snapshot? (I do have a simple ZFS pool running > on a test machine, but I've never done a snapshot.) > . . . There is: "man zfs-snapshot" for "zfs snapshot" commands. I mention this in part because it references also using "zfs promote" to swap around the status of what is a snapshot vs. what is not. There is also the man page, accessible via: "man zfs-promote" . man zfs-snapshot also mentions destroying snapshots via "zfs destroy". The man pages have examples, such as: Example 1: Creating a ZFS Snapshot The following command creates a snapshot named yesterday. This snapshot is mounted on demand in the .zfs/snapshot directory at the root of the pool/home/bob file system. # zfs snapshot pool/home/bob@yesterday Example 3 involves all 3 operations (snapshot, promote, destroy) that I've referenced: Example 3: Promoting a ZFS Clone The following commands illustrate how to test out changes to a file system, and then replace the original file system with the changed one, using clones, clone promotion, and renaming: # zfs create pool/project/production populate /pool/project/production with data # zfs snapshot pool/project/production@today # zfs clone pool/project/production@today pool/project/beta make changes to /pool/project/beta and test them # zfs promote pool/project/beta # zfs rename pool/project/production pool/project/legacy # zfs rename pool/project/beta pool/project/production once the legacy version is no longer needed, it can be destroyed # zfs destroy pool/project/legacy The description of "zfs promote" is: DESCRIPTION The zfs promote command makes it possible to destroy the dataset that the clone was created from. The clone parent-child dependency relationship is reversed, so that the origin dataset becomes a clone of the specified dataset. The snapshot that was cloned, and any snapshots previous to this snapshot, are now owned by the promoted clone. The space they use moves from the origin dataset to the promoted clone, so enough space must be available to accommodate these snapshots. No new space is consumed by this operation, but the space accounting is adjusted. The promoted clone must not have any conflicting snapshot names of its own. The zfs rename subcommand can be used to rename any conflicting snapshots. === Mark Millard marklmi at yahoo.com
Re: Request for Testing: TCP RACK
> On Nov 16, 2023, at 5:13 PM, tue...@freebsd.org wrote: > > Dear all, > > recently the main branch was changed to build the TCP RACK stack > which is a loadable kernel module, by default: > https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > > As discussed on the bi-weekly transport call, it would be great if people > could test the RACK stack for their workload. Please report any problems to > the > net@ mailing list or open an issue in the bug tracker and drop me a note via > email. > This includes regressions in CPU usage, regressions in performance or any > other > unexpected change you observe. I see some performance regression with the rack stack. This is iperf3 test on local host (bare metal, an old i5 2 cores 4 threads MBP). freebsd:16.1 Gbits/sec rack: 12.3 Gbits/sec The congestion control algorithm is cubic. Note this is a quick test with DEBUG options enabled. I'll try with no debug options and report later. > > You can load the kernel module using > kldload tcp_rack > > You can make the RACK stack the default stack using > sysctl net.inet.tcp.functions_default=rack > > Based on the feedback we get, the default stack might be switched to the > RACK stack. > > Please let me know if you have any questions. > > Best regards > Michael > > > Best regards, Zhenlei
Re: NFS exports of ZFS snapshots broken
On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > > On 17 Nov 2023, at 22:14, Mike Karels wrote: > > > On 17 Nov 2023, at 21:24, Rick Macklem wrote: > > > >> Most of the changes in stable/13 that are not in releng/13.2 > >> are the "make it work in a jail" stuff. Unfortunately, they are > >> a large # of changes (mostly trivial edits adding vnet macros), > >> but it also includes export check changes. > >> > >> I have attached a trivial patch that I think disables the export > >> checks for jails. If either of you can try it and see if it fixes > >> the problem, that would be great. > >> (Note that this is only for testing, although it probably does not > >> matter unless you are running nfsd(8) in vnet jails.) > > > > Yes, I can see snapshots with the patch. This system is just a test > > system that doesn't normally run ZFS or NFS, so no problem messing > > with permissions. It's a bhyve VM, so I just added a small disk and > > enabled ZFS for testing. > > btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > side. It must be doing something differently inside a snapshot than > outside, maybe with file handles or something like that. Yes. I've added freebsd-current@ (although Garrett is not on it, he is cc'd) and these guys specifically... So, here's what appears to be the problem... Commit 88175af (in main and stable/13, but not 13.2) added checks for nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred used when the file system is exported. When mnt_exjail is found NULL, the current nfsd code assumes that there is no access allowed for the mount. My vague understanding is that when a ZFS snapshot is accessed, it is "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that mnt_exjail is NULL as a result. Since I do not know the ZFS code and don't even have an easy way to test this (thankfully Mike can test easily), I do not know what to do from here? Is there a "struct mount" constructed for this pseudo mount (or it actually appears to be the lookup of ".." that fails, so it might be the parent of the snapshot subdir?)? One thought is that I can check to see if the mount pointer is in the mountlist (I don't think the snapshot's mount is in the mountlist) and avoid the jail test for this case. This would assume that snapshots are always within the file system(s) exported via that jail (which includes the case of prison0, of course), so that they do not need a separate jail check. If this doesn't work, there will need to be some sort of messing about in ZFS to set mnt_exjail for these. I will try and get a test setup going here, which leads me to.. how do I create a ZFS snapshot? (I do have a simple ZFS pool running on a test machine, but I've never done a snapshot.) Although this problem is not in 13.2, it will have shipped in 14.0. Any help with be appreciated, rick > > Mike > > > >> rick > >> > >> On Fri, Nov 17, 2023 at 6:14 PM 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 > >>> ith...@uoguelph.ca. > >>> > >>> > >>> Rick, have you been following this thread on freebsd-stable? I have been > >>> able > >>> to reproduce this using a 13-stable server from Oct 7 and a 15-current > >>> system > >>> that is up to date using NFSv3. I did not reproduce with a 13.2 server. > >>> The > >>> client was running 13.2. Any ideas? A full bisect seems fairly painful, > >>> but > >>> maybe you have an idea of points to try. Fortunately, these are all test > >>> systems that I can reboot at will. > >>> > >>> Mike > >>> > >>> Forwarded message: > >>> > From: Garrett Wollman > To: Mike Karels > Cc: freebsd-sta...@freebsd.org > Subject: Re: NFS exports of ZFS snapshots broken > Date: Fri, 17 Nov 2023 17:35:04 -0500 > > < said: > > > I have not run into this, so I tried it just now. I had no problem. > > The server is 13.2, fully patched, the client is up-to-date -current, > > and the mount is v4. > > On my 13.2 client and 13-stable server, I see: > > 25034 ls CALL > open(0x237d32f9a000,0x120004) > 25034 ls NAMI "/mnt/tools/.zfs/snapshot/weekly-2023-45" > 25034 ls RET open 4 > 25034 ls CALL fcntl(0x4,F_ISUNIONSTACK,0x0) > 25034 ls RET fcntl 0 > 25034 ls CALL > getdirentries(0x4,0x237d32faa000,0x1000,0x237d32fa7028) > 25034 ls RET getdirentries -1 errno 5 Input/output error > 25034 ls CALL close(0x4) > 25034 ls RET close 0 > 25034 ls CALL exit(0) > > Certainly a libc bug here that getdirentries(2) returning [EIO] > results in ls(1) returning EXIT_SUCCESS, but the [EIO] error i
Re: autofs -hosts maps
On 11/18/23 07:13, Daniel Braniss wrote: On 18 Nov 2023, at 5:47, Cy Schubert wrote: Hi, The discussion about NFS exports of ZFS snapshots prompted me to play around with -hosts maps on my network. -hosts maps are mounted on /net. I've discovered that -hosts maps don't work with most shares but do with others. I've only played with this for a few minutes so I don't fully understand why some maps work and others not. Some of underlying directories that don't work are ZFS while others are UFS. Yet, auto_home maps mounting the same directories does work. And mounting the shares by hand (using mount_nfs) also works. Just putting this out there should someone else have noticed this. I'll play around with this a little over the weekend. it’s subdirectories that don’t work? if so it’s a bug/feature of -hosts. danny -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 Daniel Braniss da...@cs.huji.ac.il Hi, Could it be related to the issue in the (old) discussion starting with this message: https://lists.freebsd.org/pipermail/freebsd-current/2014-September/051969.html -- Kind regards, Hans Ottevanger Eindhoven, Netherlands h...@beastielabs.net www.beastielabs.net
Re: Request for Testing: TCP RACK
> On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote: > > On Fri, 17 Nov 2023 18:51:05 +0100 > tue...@freebsd.org wrote: > >>> On Nov 17, 2023, at 17:06, Johan Hendriks wrote: >>> >>> I am running the rack stack for quiet some time now on a baremetal machiene >>> and never had problems. >>> Also use pf. This is a test machine so not a lot happening on it. >>> >>> Are there any thing we can test? Do we have some test scripts we can run? >> We are actually interested in feedback about using the stack in whatever >> use case you use TCP for. The stack has been tested with the Netflix use >> case, but not so much with others. That is why we ask for broader testing. >> >> Best regards >> Michael > > Are there any difference regarding with performance between main and > stable/14? If so, please ignore below. > > I have stable/14 environment which is configured to be able to switch > to TCP RACK and experienced huge performance loss when writing > a large file to smbfs share on commercial NAS. CC is cubic. > Testing large archive on the smbfs share doesn't seem to be > affected. > > Comparison between default (freebsd) and rack TCP stack using > sysutils/clone on stable/14 at commit 7d1321288ad9, amd64. > Last 3 lines of outputs from clone (upload to NAS) are shown. Thank you very much for testing. This is what we are looking for. Would it be possible to repeat the test using NewReno as the CC? Best regards Michael > > Before switching to rack: > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > Leaked memory: 0 bytes > No errors occured. > > Unmount the smbfs share, switch to rack, and after remount: > 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s > Leaked memory: 0 bytes > No errors occured. > > Switch back to freebsd (default) without unmounting: > 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s > Leaked memory: 0 bytes > No errors occured. > > Unmount and remount the smbfs share: > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > Leaked memory: 0 bytes > No errors occured. > > > Regards. > > -- > Tomoaki AOKI
