Re: using interface groups in pf tables stopped working in 13.0-RELEASE
On 14 Apr 2021, at 16:16, Peter Ankerstål wrote:
In pf I use the interface group syntax alot to make the configuration
more readable. All interfaces are assigned to a group representing its
use/vlan name.
For example:
ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"
ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’
up"
ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”
in pf.conf I use these group names all over the place. But since I
upgraded to 13.0-RELEASE it no longer works to define a table using
the :network syntax and interface groups:
tableconst { trusted:network mgmt:network
dmz:network guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
I can reproduce that.
It looks like there’s some confusion inside pfctl about the network
group. It ends up in pfctl_parser.c, append_addr_host(), and expects an
AF_INET or AF_INET6, but instead gets an AF_LINK.
It’s probably related to 250994 or possibly
d2568b024da283bd2b88a633eecfc9abf240b3d8.
Either way it’s pretty deep in a part of the pfctl code I don’t much
like. I’ll try to poke at it some more over the weekend.
Best regards,
Kristof
___
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-update and speed
> On 16 Apr 2021, at 13:46, Stefan Esser wrote: > > There was a discussion about adding another mirror in Europe, but > it was decided that a suitable system already existed. > > Not sure whether this mirror actually has been provided, but I do > remember that it should have been a well connected system (maybe in > NL?) that has been selected to perform all FreeBSD mirror services > for users in Europe with little latency and high throughput. > > Regards, STefan > I use gitup with git.freebsd.org and it connects to gitmir.pkt.freebsd.org which is in Netherlands. My servers are in Germany and I get good speed. portsnap uses "AWS Global Accelerator" and while I use it I was getting good speeds too. I am not familiar with freebsd-update as I build from source, but update.freebsd.org points to update1.freebsd.org , update2.freebsd.org and update4.freebsd.org which are not in Europe. Does any freebsd-update mirror exist in Europe? ___ 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-update and speed
On Fri, 16 Apr 2021, Andrea Brancatelli wrote: I was experiencing the same problem and modified freebsd-update's config file to point directly to one of the other server, can't remember if update1 or update2 and it was fast. I just tried update1 and it really was considerably faster. Might have been a coincidence... I'll see when I do the next updates in a few days. Anyway this should be something I'd like the freebsd-update utility to by itsself: Choose a fast mirror. Or at least have a documented way on how to adjust this instead of trial and error. Regards Ferdinand smime.p7s Description: S/MIME Cryptographic Signature
Re: freebsd-update and speed
Am 16.04.21 um 10:17 schrieb Ferdinand Goldmann: On Thu, 15 Apr 2021, Rainer Duffner wrote: It’s OK-ish most of the time here (CH). It does *NOT* work through a proxy, due to the use of pipelined http-requests. What’s your internet-connection? The 10Gbit uplink of my university, directly connected to the internet, not behind a proxy. I don't think that's the problem. When update3 was still online I'd always use that and updates were really fast back then. Now that update3 is gone all update servers seem to be in the US or Australia. After waiting for nearly one hour: ..853085408550856085708580859086008610862086308640865086608670868086908700 done. Applying patches... done. Fetching 9628 files... gunzip: (stdin): unexpected end of file 0a4626107f3700cf5f87bd9c123bf427bd5a8561aadc2eca1d1605465c090935 has incorrect hash. This is getting kind of tiresome. :( There was a discussion about adding another mirror in Europe, but it was decided that a suitable system already existed. Not sure whether this mirror actually has been provided, but I do remember that it should have been a well connected system (maybe in NL?) that has been selected to perform all FreeBSD mirror services for users in Europe with little latency and high throughput. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: freebsd-update and speed
On Thu, 15 Apr 2021, Rainer Duffner wrote: It’s OK-ish most of the time here (CH). It does *NOT* work through a proxy, due to the use of pipelined http-requests. What’s your internet-connection? The 10Gbit uplink of my university, directly connected to the internet, not behind a proxy. I don't think that's the problem. When update3 was still online I'd always use that and updates were really fast back then. Now that update3 is gone all update servers seem to be in the US or Australia. After waiting for nearly one hour: ..853085408550856085708580859086008610862086308640865086608670868086908700 done. Applying patches... done. Fetching 9628 files... gunzip: (stdin): unexpected end of file 0a4626107f3700cf5f87bd9c123bf427bd5a8561aadc2eca1d1605465c090935 has incorrect hash. This is getting kind of tiresome. :( Regards Ferdinand smime.p7s Description: S/MIME Cryptographic Signature
Re: freebsd-update and speed
On 2021-04-15 14:20, Ferdinand Goldmann wrote: > I've noticed that ever since update3.freebsd.org is gone (which was in Czech > republic I think), FreeBSD updates are often quite slow for me (= > Austria/Europe) > Especially so for major release upgrades. In fact so slow that I have time > to type this mail while waiting for '8778 patches'. I was experiencing the same problem and modified freebsd-update's config file to point directly to one of the other server, can't remember if update1 or update2 and it was fast. --- Andrea Brancatelli ___ 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: Frequent disk I/O stalls while building (poudriere), processes in "zfs tear" state
* Dewayne Geraghty [20210416 06:26]:
> On 16/04/2021 2:29 am, Felix Palmen wrote:
> > Right now, I'm running a test with idprio 0 instead, which still seems
> > to have the desired effect, and so far, I didn't have any of these
> > stalls. If this persists, the problem is solved for me!
> >
> > I'd still be curious about what might be the cause, and, what this state
> > "zfs tear" actually means. But that's kind of an "academic interest"
> > now.
>
> Most likely your other processes are pre-empting your build, which is
> what you want :).
Yes, that's exactly the plan.
> Use /usr/bin/top to see the priority of the processes (ie under the PRI
> column). Using an idprio 22, means (on my 12.2Stable) a PRI of 146. If
> your kern.sched.preempt_thresh is using the default (of 80) then
> processes with a PRI of <80 will preempt (for IO).
I was doing that a lot, that's how I found those "global" I/O stalls
were happening when some processes were in that "zfs tear" state (shown
in top only as "zfs te").
> Even with an idprio 0, the PRI is 124. So I suspect that was more a
> matter of timing (ie good luck).
That seems kind of unlikely because the behavior is pretty reproducible.
Having observed builds on idprio 0 (yes, this results in a priority of
124) for a while, I still see from time to time processes getting
"stuck" for a few seconds, mostly ccache processes, but now in state
"zfsvfs" and the rest of the system is not affected, I/O still works.
So, something did change with ZFS and priorities between 12.2 and 13.0.
Running the whole builds on idprio 22 worked fine on 12.2.
> You could increase your pre-emption threshold for the duration of the
> build, to include your nice value. But... (not really a good idea).
That would clearly defeat the purpose, yes ;)
> Re zfs - sorry, I'm peculiar and don't use it ;)
I suspect the relevant change to be exactly in that context, still
thanks for answering :) Now that I have a working solution, it isn't an
important issue for me any more. Curiosity remains…
--
Dipl.-Inform. Felix Palmen ,.//..
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A
signature.asc
Description: PGP signature
