Re: FreeBSD NFSv4.1/4.2 server is broken when Linux mounts use "nconnects"

[Alan Somers]

On Fri, Apr 2, 2021 at 4:16 PM Rick Macklem  wrote:

> Alan Somers wrote:
> >On Mon, Mar 29, 2021 at 3:52 PM Rick Macklem  > wrote:
> >>Hi,
> >>
> >>The FreeBSD NFS server is broken when handling multiple
> >>connections for NFSv4.1/4.2.
> >>It incorrectly binds the back channel to a new connection
> >>when is sees an RPC with Sequence in it (almost all RPCs)
> >>and might send a callback on the wrong connection.
> >>
> >>I have a fix, but it won't be in a release until 12.3/13.1.
> >>It can be found in Bugzilla PR#254560.
> >>
> >>In the meantime, avoid using the "nconnects" option
> >>on Linux client mounts.
> >>
> >>Thanks go to Ben Coddington @redhat for diagnosing
> >>this and testing the patch.
> >>
> >>Sorry about the breakage, rick
> >>ps: It was done intentionally long ago, when clients
> >>  did not do BindConnectionToSession and then slipped
> >>  through the cracks.
> >
> >I've tested the patch and it works.  Specifically:
> >
> >* Without the patch and without nconnect, everything works on both 12.2
> and 13.0.
> >* Without the patch, with nconnect, and without delegations, everything
> works on 12.2, but on 13.0 clients lock up >when they try file I/O.
> Hmm. The 12.2 and 13.0 code is the same w.r.t. The only difference I can
> think of
> is that 13.0 has 4.2 in it and Linux tends to use the newest version
> supported by the server.
>

All mounts were exactly version 4.1.  However, I wasn't testing exactly the
same Linux kernel version with 12.2 as I did with 13.0.  That might be the
difference.


>
> >* Without the patch, with nconnect, and with delegations, clients lock up
> on both 12.2 and 13.0.
> >* With the patch on 13.0, everything works even with nconnect and
> delegations.
> thanks for doing the testing, although it would have been more fun to
> crash the Linux systems.;-)
>
> >I haven't tried backporting the patch to 12.2 yet.
> The code hasn't changed in a long time, so it should drop in without
> difficulty, but it also
> probably doesn't need testing.
>
> rick
> ps: I've already committed it to current/main.
>
> -Alan
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD NFSv4.1/4.2 server is broken when Linux mounts use "nconnects"

[Rick Macklem]

Alan Somers wrote:
>On Mon, Mar 29, 2021 at 3:52 PM Rick Macklem 
>mailto:rmack...@uoguelph.ca>> wrote:
>>Hi,
>>
>>The FreeBSD NFS server is broken when handling multiple
>>connections for NFSv4.1/4.2.
>>It incorrectly binds the back channel to a new connection
>>when is sees an RPC with Sequence in it (almost all RPCs)
>>and might send a callback on the wrong connection.
>>
>>I have a fix, but it won't be in a release until 12.3/13.1.
>>It can be found in Bugzilla PR#254560.
>>
>>In the meantime, avoid using the "nconnects" option
>>on Linux client mounts.
>>
>>Thanks go to Ben Coddington @redhat for diagnosing
>>this and testing the patch.
>>
>>Sorry about the breakage, rick
>>ps: It was done intentionally long ago, when clients
>>  did not do BindConnectionToSession and then slipped
>>  through the cracks.
>
>I've tested the patch and it works.  Specifically:
>
>* Without the patch and without nconnect, everything works on both 12.2 and 
>13.0.
>* Without the patch, with nconnect, and without delegations, everything works 
>on 12.2, but on 13.0 clients lock up >when they try file I/O.
Hmm. The 12.2 and 13.0 code is the same w.r.t. The only difference I can think 
of
is that 13.0 has 4.2 in it and Linux tends to use the newest version supported 
by the server.

>* Without the patch, with nconnect, and with delegations, clients lock up on 
>both 12.2 and 13.0.
>* With the patch on 13.0, everything works even with nconnect and delegations.
thanks for doing the testing, although it would have been more fun to crash the 
Linux systems.;-)

>I haven't tried backporting the patch to 12.2 yet.
The code hasn't changed in a long time, so it should drop in without 
difficulty, but it also
probably doesn't need testing.

rick
ps: I've already committed it to current/main.

-Alan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD NFSv4.1/4.2 server is broken when Linux mounts use "nconnects"

[Alan Somers]

On Mon, Mar 29, 2021 at 3:52 PM Rick Macklem  wrote:

> Hi,
>
> The FreeBSD NFS server is broken when handling multiple
> connections for NFSv4.1/4.2.
> It incorrectly binds the back channel to a new connection
> when is sees an RPC with Sequence in it (almost all RPCs)
> and might send a callback on the wrong connection.
>
> I have a fix, but it won't be in a release until 12.3/13.1.
> It can be found in Bugzilla PR#254560.
>
> In the meantime, avoid using the "nconnects" option
> on Linux client mounts.
>
> Thanks go to Ben Coddington @redhat for diagnosing
> this and testing the patch.
>
> Sorry about the breakage, rick
> ps: It was done intentionally long ago, when clients
>   did not do BindConnectionToSession and then slipped
>   through the cracks.
>

I've tested the patch and it works.  Specifically:

* Without the patch and without nconnect, everything works on both 12.2 and
13.0.
* Without the patch, with nconnect, and without delegations, everything
works on 12.2, but on 13.0 clients lock up when they try file I/O.
* Without the patch, with nconnect, and with delegations, clients lock up
on both 12.2 and 13.0.
* With the patch on 13.0, everything works even with nconnect and
delegations.

I haven't tried backporting the patch to 12.2 yet.
-Alan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays?

[John Kennedy]

On Thu, Apr 01, 2021 at 07:18:56PM -1000, parv/freebsd wrote:
> On Thu, Apr 1, 2021 at 3:38 PM parv/freebsd wrote:
> 
> I am wondering if $SRC_BASE, $MAKEOBJDIRPREFIX, & $WRKDIRPREFIX being
> ZFS datasets now would increase compile time. I will found that out in
> few weeks (in case of buildworld & kernel) as earlier I had both $SRC_BASE &
> $MAKEOBJDIRPREFIX as plain directories & took ~5--6 hours.
> 
> I have FreeBSD 12-STABLE in VirtualBox 5.2.44 on Windows 10. All the "disks"
> > are file-backed virtual disks.
> >
> > I noticed that after making $HOME a ZFS dataset, there were delays ...
> > - generally in start of Xorg;
> > - exhibited by xauth (after using "startx") error messages about timeout
> >   with authority files.
> >
> > After reverting back $HOME not being a dataset on its own as before, there
> > are no delays in start of Xorg; nor are any timeout message from xauth as
> > before.
> >
> > Has anybody else noticed that?

  I can't say that I've noticed any slowness.  I normally don't use xauth
unless I'm doing something exotic (like su to another user but want to have
them able to use my X display), so probably not the best example.  I've
also been using zfs on FreeBSD in favor of any other filesystem since it was
an option, so I'm probably probably totally worthless for speed comparison.

  That being said...

  I often feel like I'm rocking the 1986 X vibes because, while I like eye
candy, that eye candy is coming with a lot of baggage.  Gnome/KDE?  Hah!  I'm
using ctwm.  But if you've got said eye candy that wants to walk your file
system tree and you've got a /home/$USER/.zfs/snapshot with lots of backups
that is magnifying your tree, something might be doing a lot more work than
the designer was originally expecting.

  As far as ZFS datasets go, I keep stock+ to keep my snapshot space low.  I
added a few things onto the stock ZFS partitioning:

zfs create -o canmount=off zroot/usr/home/$USER
zfs create zroot/usr/home/$USER/.cache
zfs create zroot/usr/home/$USER/.mozilla

zfs create zroot/usr/ports/distfiles
zfs create -o canmount=off zroot/usr/obj
zfs create zroot/usr/obj/usr

zfs create zroot/poudriere

  So /home -> /usr/home is a dataset by default, /home/$USER isn't (I'm the
only user, so I wasn't worried there), but because I like doing snapshot
backups of things and I noticed that my snapshots were pretty damn big for
what I was working on, I decided to strip out the browser droppings by
making a dataset for .cache and .mozilla.  Doesn't scale, but just me.

  To keep my zroot/ROOT/default and boot environments clean, I created the
datasets for /usr/obj (kernel objects) because that is generally disposable
(except when I was doing RPI work and that was precious gold since it took
days to rebuild and I might want it to match a kernel I reverted to).  I
added oen for /usr/ports/distfiles to keep it from bloating out /usr/ports,
which is also easily reconstructed (vs the tarballs, which sometimes go AWOL).

  In any case, for /usr/obj, some variation of this is what I was looking at:

# df -h / /usr/obj/usr
FilesystemSizeUsed   Avail Capacity  Mounted on
zroot/ROOT/default 67G4.2G 63G 6%/
zroot/usr/obj/usr  72G8.6G 63G12%/usr/obj/usr

  I do not need 8G of stuff that I'll probably never use again snapshotted with
my root filesystem that I may keep around for extended periods of time.  On
disk, each of the roots generally seems to use ~1.2G of space with what they
have in common, but I wasn't going to get that with /usr/obj.

  Now, I've got a pretty beefy box, so my compiling pain points may not match
yours but you can do things like tune the datasets.  For example, if you're
CPU bound and you have a lot of compression on /usr/obj, you may want to turn
that off (while being able to leave it on for the root partition).

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays?

[parv]

Hi there,

I have FreeBSD 12-STABLE in VirtualBox 5.2.44 on Windows 10. All the "disks"
are file-backed virtual disks.

I noticed that after making $HOME a ZFS dataset, there were delays ...
- generally in start of Xorg;
- exhibited by xauth (after using "startx") error messages about timeout
  with authority files.

After reverting back $HOME not being a dataset on its own as before, there
are
no delays in start of Xorg; nor are any timeout message from xauth as
before.

Has anybody else noticed that?


  - parv


Before making $HOME (/aux/home/parv) a dataset ...

  aux0 mounted at /aux
  aux0/home at /aux/home

Conversion of $HOME to a dataset ..

  % zfs create aux0/home/parv2
  % mv /aux/home/parv/* /aux/home/parv2/
  % mv /aux/home/parv/.* /aux/home/parv2/
  % rm -rf /aux/home/parv
  % zfs rename aux0/home/parv2 aux0/home/parv
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"