Re: autofs -hosts maps
> 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
autofs -hosts maps
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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 ÀÀÀÀÀÀÀÀ
Update to the Release Engineering Team Roster
-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-
Re: Request for Testing: TCP RACK
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. 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
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Fri, Nov 17, 2023 at 11:00:07AM +0100, Olivier Certner wrote: > Hi Glen, > > > I also agree we cannot prevent people from downloading the images, > > installers, whatever before the announcement. That is the lovely race > > condition with which we have to live at the moment. > > Yes, and given that, I don't think you did anything wrong. > > It seems that the race is the same for freebsd-update(8), according to "The > Doctor". But maybe in this case it is easier to fix, perhaps if installing > the metadata signaling the new release to it can be delayed, by contrast with > big files containing the actual data (I don't know how freebsd-update(8) > works, so this is just a guess). > > > The alternative would be to say nothing at all. > > I really hope you and re@ will never choose this way. > > > Either way, it is a productivity, communication drain. It is > > a lose-lose situation no matter how one looks at it given the above > > context. We either get chastised for being "too open" into insights > > delaying an official announcement, or for being "not open enough" when > > there is silence from RE when a release does not meet its scheduled > > announcement date. > > IMHO, a delay should always be announced (perhaps unless it's only a few > days). If it is too hard to decide on the right level of details, then only > mention that some (potential or verified) problem is being looked upon, but > don't let that prevent you from communicating. > > As for people saying that they have already installed the "release", I'd > suggest to have some text on the website (https://www.freebsd.org/releng/ > perhaps) explaining that images on mirrors can appear in advance of release > announcements and that they should not be considered as official until the > official mail is sent, and just kindly point them to it. I hope this can > contribute to at least attenuating the drain you're experiencing. > > Regards. > > -- > Olivier Certner > > just a suggestion for the future is that to have some sort of gpg/gpg check in freebsd-update . -- Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen Lest we forget 11 Nov 2023 Beware https://mindspring.com
Re: Request for Testing: TCP RACK
> 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 > > > >
Re: Request for Testing: TCP RACK
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?
Re: Request for Testing: TCP RACK
Am 2023-11-17 14:29, schrieb void: On Thu, Nov 16, 2023 at 10:13:05AM +0100, tue...@freebsd.org wrote: 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 Hi, thank you for this. https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ mentions this needs to be set in /etc/src.conf : WITH_EXTRA_TCP_STACKS=1 Is this still the case? Context here is -current both in a vm and bare metal, on various machines, on various connections, from DSL to 10Gb. On a recent -current: this is not needed anymore, it is part of the defaults now. But you may still compile the kernel with "option TCPHPTS" (until it's added to the defaults too). Is there a method (yet) for enabling this functionality in various -RELENG maybe where one can compile in a vm built for that purpose, then transferring to the production vm? Copy the kernel which was build according to the acticle from klara systems to your target VM. Would it be expected to work on arm64? Yes (I use it on an ampere VM in the cloud). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: Request for Testing: TCP RACK
Hi, On Fri, Nov 17, 2023 at 02:46:52PM +0100, Olivier Cochard-Labbé wrote: > On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra wrote: > > > > > 1. It even fails with a simple pf.conf: > >pass in all > >pass out all > > > > 2. Fetching port distfiles also failed. > > > > 3. If I disable rxcsum on the ethernet adapter (igb0) it works. > > > > > I can't reproduce it with pfctl too (same igb drivers with default RXCSUM > enabled). > > $ cat /etc/pf.conf > pass in all > pass out all > $ service pf onestart > Enabling pf > . > $ pfctl -sr > pass in all flags S/SA keep state > pass out all flags S/SA keep state > $ sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: rack > $ ifconfig igb0 | grep option > > options=4e523bb > nd6 options=21 > > $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working > working > > What is your igb chipset exactly ? (pciconf -lv | grep -B 3 -F "network") igb0@pci0:41:0:0: class=0x02 rev=0x03 hdr=0x00 vendor=0x8086 device=0x1533 subvendor=0x1849 subdevice=0x1533 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network > What is your netstat -ss output ? tcp: 946 packets sent 933 data packets (41681 bytes) 7946 ack-only packets (2 delayed) 1 control packet 999 packets received 860 acks (for 41681 bytes) 910 packets (118790 bytes) received in-sequence 12 completely duplicate packets (17136 bytes) 1 connection request 1 connection established (including accepts) 1 time used RTT from hostcache 1 time used RTT variance from hostcache 1 connection closed (including 1 drop) 1 connection updated cached RTT on close 1 connection updated cached RTT variance on close 862 segments updated rtt (of 847 attempts) 71 correct ACK header predictions 124 correct data packet header predictions 7910 SACK options (SACK blocks) sent TCP connection count by state: 7 connections in LISTEN state 1 connection in ESTABLISHED state udp: 39 datagrams received 39 delivered 39 datagrams output ip: 80 total packets received 23 packets for this host 23 packets sent from this host icmp: ICMP address mask responses are disabled igmp: arp: ip6: 933 total packets received 931 packets for this host 8891 packets sent from this host Input histogram: TCP: 915 UDP: 16 ICMP6: 2 Mbuf statistics: 870 one mbuf 63 one ext mbuf 0 two or more ext mbuf source addresses on an outgoing I/F 2 link-locals 3 globals source addresses of same scope 2 link-locals 3 globals Source addresses selection rule applied: 5 first candidate 3 appropriate scope icmp6: Output histogram: neighbor solicitation: 2 Input histogram: neighbor advertisement: 2 Histogram of error messages to be generated: rip6: Thanks. -- Herbert
Re: Request for Testing: TCP RACK
On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra wrote: > > 1. It even fails with a simple pf.conf: >pass in all >pass out all > > 2. Fetching port distfiles also failed. > > 3. If I disable rxcsum on the ethernet adapter (igb0) it works. > > > I can't reproduce it with pfctl too (same igb drivers with default RXCSUM enabled). $ cat /etc/pf.conf pass in all pass out all $ service pf onestart Enabling pf . $ pfctl -sr pass in all flags S/SA keep state pass out all flags S/SA keep state $ sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: rack $ ifconfig igb0 | grep option options=4e523bb nd6 options=21 $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working working What is your igb chipset exactly ? (pciconf -lv | grep -B 3 -F "network") What is your netstat -ss output ?
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Glen Barber wrote: > No. It merely suggests the release is not officially official yet. Ok. Thanks for the clarification. Jamie.
Re: Request for Testing: TCP RACK
Hi, On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote: > > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote: > > > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote: > >> > >> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra > >> wrote: > >> > >>> > >>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS". > >>> > >>> After setting "sysctl net.inet.tcp.functions_default=rack" git no > >>> longer works: > >>> > >>> > >> Are you using a fresh 15 head or a specific network setup ? > >> > >> Because I'm not able to reproduce your problem on my system: > >> > >> $ uname -a > >> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0 > >> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023 > >> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS > >> amd64 > >> $ cat /usr/src/sys/amd64/conf/TCPHPTS > >> include GENERIC-NODEBUG > >> ident TCPHPTS > >> options TCPHPTS > >> $ sysctl net.inet.tcp.functions_default > >> net.inet.tcp.functions_default: rack > >> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working > >> working > >> $ > > > > OK, (g)it works if I disable pf. Do you use pf? > Can you share your pf config such that I can reproduce the problem locally? 1. It even fails with a simple pf.conf: pass in all pass out all 2. Fetching port distfiles also failed. 3. If I disable rxcsum on the ethernet adapter (igb0) it works. Thanks. -- Herbert
Re: Request for Testing: TCP RACK
On Thu, Nov 16, 2023 at 10:13:05AM +0100, tue...@freebsd.org wrote: 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 Hi, thank you for this. https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ mentions this needs to be set in /etc/src.conf : WITH_EXTRA_TCP_STACKS=1 Is this still the case? Context here is -current both in a vm and bare metal, on various machines, on various connections, from DSL to 10Gb. Is there a method (yet) for enabling this functionality in various -RELENG maybe where one can compile in a vm built for that purpose, then transferring to the production vm? Would it be expected to work on arm64? What testing would you like doing? --
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Hi Glen, > I also agree we cannot prevent people from downloading the images, > installers, whatever before the announcement. That is the lovely race > condition with which we have to live at the moment. Yes, and given that, I don't think you did anything wrong. It seems that the race is the same for freebsd-update(8), according to "The Doctor". But maybe in this case it is easier to fix, perhaps if installing the metadata signaling the new release to it can be delayed, by contrast with big files containing the actual data (I don't know how freebsd-update(8) works, so this is just a guess). > The alternative would be to say nothing at all. I really hope you and re@ will never choose this way. > Either way, it is a productivity, communication drain. It is > a lose-lose situation no matter how one looks at it given the above > context. We either get chastised for being "too open" into insights > delaying an official announcement, or for being "not open enough" when > there is silence from RE when a release does not meet its scheduled > announcement date. IMHO, a delay should always be announced (perhaps unless it's only a few days). If it is too hard to decide on the right level of details, then only mention that some (potential or verified) problem is being looked upon, but don't let that prevent you from communicating. As for people saying that they have already installed the "release", I'd suggest to have some text on the website (https://www.freebsd.org/releng/ perhaps) explaining that images on mirrors can appear in advance of release announcements and that they should not be considered as official until the official mail is sent, and just kindly point them to it. I hope this can contribute to at least attenuating the drain you're experiencing. Regards. -- Olivier Certner
