Messages

Maybe something shows up in the output of

Code Select Expand

zpool events -v zrootafter boot?

Pool data integrity (checksums) can be verified with

Code Select Expand

zpool scrub zrootthen wait a minute or so, and finally run

Code Select Expand

zpool status zrootto make sure that all error counts are zero.

You could make the error disappear by setting the tunable vfs.aio.enable_unsafe = 1 (https://man.freebsd.org/cgi/man.cgi?query=aio, second paragraph). But I'm not sure if that is safe and would not recommend it in production.

Disclaimer: I am not a ZFS developer but took a quick look at their code base.

It happens when the zpool is imported and ZFS attempts AIO on file descriptors where FreeBSD thinks it is not safe to do so. In such a case FreeBSD raises the EOPNOTSUPP errno (https://man.freebsd.org/cgi/man.cgi?query=aio_read&sektion=2&n=1). That is not an issue - ZFS simply tries again, the second time without AIO.

For the details, look here: https://github.com/openzfs/zfs/blob/6ba51da93b01b5636e7eea48a325bedf3fc4d36a/lib/libzutil/zutil_import.c#L1076 . If EOPNOTSUPP is set, the switch statement falls through such that do_slow is set to true and on line 1086 the second, "slow" attempt is performed.

So, in my (unqualified) opinion, there is no reason to be concerned about this message. Your zpool is imported correctly and you still  benefit from asynchronous I/O.

--

Run a firmware update to include today's hotfix 25.7.3_3 - this should fix the issue for you

Great, thanks a lot for the quick reaction franco!

I can confirm that in 25.7.3_3 all these internal pf tables are populated again on my system.

Hi,

is it normal that automatically generated firewall aliases (LAN, WAN, loopback, etc.) always show up as empty in Firewall -> Diagnostics -> Aliases? See attachment screenshots for an example. Other aliases (e.g. bogons) show up with content as expected.

No errors appear in the backend log, just the normal notices. The generated aliases are functioning in firewall rules (hence they cannot be empty).

tour.in is registered but the name servers are not reachable. Anyone on your network planning to travel to India?

https://www.whois.com/whois/tour.in

Thank you, confusion elininated :-)

Maybe we should start a list of ISPs where baby jumbo frames work.

Hi,

as a computer networking newbie I struggle to understand why the VLAN tag has to be considered when setting these MTU values. The 802.1Q VLAN tag is an optional part of the Ethernet header. The MTU values in FreeBSD and other operating systems describe the payload of the Ethernet frame, which is independent of the Ethernet header (except for the allowed minimum payload). Hence, to my understanding, if a VLAN is stacked on another interface in FreeBSD it changes the length of the Ethernet header, not the size of the payload. Therefore FreeBSD allows you to set the MTU of a VLAN equal to the MTU of its parent interface (or smaller, of course).
With this reasoning the baby jumbo frames for PPPoE would always have a MTU of 1508 bytes to accomodate for the 8 byte the PPP header, regardless of whether there is an "ISP customer VLAN" stacked on top or not, because the VLAN tag is not part of the payload but part of the encapsulating Ethernet header. The size of the Ethernet frame varies of course by 4 byte, but the payload stays the same.
What am I missing here? Is the VLAN tag somehow entering the PPPoE payload?

PS @meyergru: thanks for being such a prolific writer here! So far I have been a silent reader and your tutorials are very helpful and taught me lot. Keep 'em coming!