well, no idea how often and how commiters look for patches that have run into maintainer timeout, the sqlite patch is by a commiter dch, so he should likely bring that foreward; for the other one maybe mentioning it here was enought to make a commiter aware of the timeout, so I would wait a day and if nobody is working on it then ask in #freebsd-ports, but well, currently are holidays, so maybe

people are away from their computers and stuff is slower

what causes state-insert (failures) in the output of pfctl -si? (state-insert state insertion failure)

kerneldove_: a full state table perhaps; do you have frequent failures?

no state table isn't full. i don't get any 'memory' errors fwiw

just state-insert and state-mismatch but only a few of those

highest i've seen current entries is like 800k and my limit is upped to 1.2M

300k searches/s

1 state-insert per sec

if you really want to know what causes it, the best way would be to read the source for it

or ask on pf@, which probably has more pf experts than this channel

Is there a way I can monitor the zfs memory consumption on 15.0?

Liaf: top(1), sysctls under vfs.zfs

I realize my question was kinda silly :-D

If I check with top I see that most of my memory is used. Only a frew MB are free. However I know that zfs uses memory for caching. I want to check how much memory is still directly available before swapping. Background is I want to check if I run into issues with 2-4GB memory.

all memory which is Inact, Buf, Free or is used by ARC is available for use by applications

So with ARC: 3000M Total that would mean this is "free" for applications?

yes, zfs will release it if an application needs more memory

So if I have a small system with 2G memory I should still be fine using ZFS as the memory consumption isn't as bad as it looks when arc shows 1252M Total?

the memory consumption is what it is -- this is no different from UFS, which also releases its cache memory when applications use it

and yes, you can use ZFS with 2GB RAM

Okay, just saw some conflicting posts that you need at least 4G. However when reading them it sounded a lot like a personal choice which file system is prefered. I just want to unserstand my own limitations if I switch to ZFS :-)

i've used ZFS with 1GB RAM and it works fine. if you have applications with bursty memory use (i.e., they like to allocate a lot of memory all at once) you may find ZFS can't release it quickly enough, in which case setting vfs.zfs.arc.max may help, but this has improved a lot in recent releases and i wouldn't do that unless you find you have to

that's allowed, no worries Liaf

Okay, I will just play around with my two test systems for now :-)

Thanks a lot for the input :-)

Liaf: it's worth setting vfs.zfs.arc_max="768M" or similiar value, dependent on your workload, in loader.conf

at some point (iirc <1G RAM) you should manually tune memory settings of zfs

Well I actually don't expect to drop below 2G. A friend uses a 2G machine and is worried so I thought I test it while dipping my feet into this topic anyway :-)

Hi there. Is it safe to directly go through system upgrade from FreeBSD 13.3-RELEASE-p7 to 15-RELEASE via freebsd-update? This is a remote box with ONLY a ssh access.

tercaL, this doesn't answer your exact question, but: Do you have the possibility of having someone power cycle the box? If yes, then you might be able to test it by updating in a boot environment and setting it to "boot once", and if there is a problem it will boot to the old boot environment on power cycle

speaking of which

I recall that the boot env "boot once" switch, betctl activate -t, was only reliable for bios (legacy) boot in the past. Has that been changed? Does the switch work for EFI boot too these days?

futune_ there should be no difference, that code does not depend on firmware type

tsoome, do you mean the code in bectl? I was kind of thinking that it was the early boot code which fails to mark the single boot as "spent" when using EFI, or something like that...

but it would be lovely if it works

n00b question but something that has always bothered me.. If multiple vnet jails share a bridge, isn't it so that all jails can see all traffic of that bridge? Meaning that plaintext traffic and encrypted traffic headers are visible to other jails too?

onlyoffice doesn't print on Fridays

lts, yes, unless you prevent them to tcpdump (no bpf interface)

Ah, compensating control

Thanks, I can be at peace now

lts, by default there's no bpf interface in devfs.rules for jails

Yup, understood

Liaf: bit late reply, but if you see people on social media saying you need 4GB/8GB to run ZFS, this is a lie, you don't. this is a very common persistent myth about ZFS

ivy: thank you. I figured that it's also stable with less memory :-)

tercaL: sure, but not in one go

futune_: you are probably thinking about nextboot facility, not zfs one

istr nextboot had issues with uefi boot back then

ivy: I think its because they assume the arc cache takes tons of memory (which it does) without realising memory which is not used is wssted anyways. The fact that zfs caches thing in the arc cache when there is spare memory is a plus not a downside

polarian: to be fair, it may be partly because in the past (around 13.x) the arc memory reclaim was not very good and it would sometimes lead to oom, but even then you could just set arc_max

ivy: ah right, well I dont ever remember having issues with zfs even on low memory devices

ivy, I always heard you want 1GB per TB of raw disk space.

CrtxReavr: i'm pretty sure that rule of thumb is for deduplication, because it needs to fit the dedup table in memory or performance drops off a cliff. but even then it depends on your usage pattern, there's no hard requirement

also, if you search "1GB per TB", the first hit is someone saying "You need 8GB minimum for ZFS" so ... take these "rules" with a large pitcher of salt

like if i was building a general purpose fileserver with 32TB of storage, i'd put at least 128GB RAM in there, there's no skimping

s/no /no point/

(well, maybe there is nowadays with the price of memory, but...)

the joys of using old devices :p

cheap memoryt

Same here, but only because ARC is great and I have spare DDR available. Otherwise it would run happily with 8GB or much less

just harvest it from some shit lying around

Looks like my backup server with roughly that amount of (raw) storage uses a whopping 1106MB of memory at the moment

Probably because it runs some bhyve vms too

backup server probably needs a lot less memory than fileserver though, that's sort of what i was getting at earlier, it really depends on your use case, not these silly rules people come up with

+1 ivy

I did always find it stupid how people say "Oh I need 128GB of memory for my storage server of 2x4TB HDDs"

I think a lot of it is just because they can, not so much because you *need* it

but memory is not some magically thing which instantly makes things faster by increasing the amount of it

my home fileserver has 64TB raw disk and 32GB RAM, but that's because i'm poor and it works fine as is :-)

Huh, I thought I asked it, but can't find it in my logs.

I was wondering, what's the status of armv7 support w.r.t. future FreeBSD now?

(ah, I found it now ... I asked in #freebsd-ports by accident)

(but didn't get a reply anyway)

What I mean is, is it still going to be removed post-15?

I just realize playing around with everything, that my old configuration needs to get updated. For a lot of things there are more modern solutions now and maybe I should go with them instead of bending an old solution.

(or 32-bit RISC-V, are there any plans of adding support for it at any point?)

DarkUranium: it is supported in 15.0 and will probably be dropped in 16.0, but a final decision hasn't been made and there was some noise around keeping it due to its status in the industry

DarkUranium: 32-bit riscv will almost certainly never be supported

DarkUranium: if you have a use-case for armv7, consider posting on arch@ in support of keeping it

Fair, thanks. I guess I better look towards NetBSD for those platforms ^^

ivy: not a strong one, TBH; I'm just a hobbyist.

i think there is a general feeling that armv7 isn't really freebsd's target market, but a lot of people are actually using freebsd on armv7 right now, so there's some conflicting goals...

cyric, yeah, I was only talking about the -t flag for bectl activate, aka nextboot

do you know if the uefi issues with that have been resolved now?

futune_: i mean the nextboot(8) which is completely unrelated to zfs

cyric, thanks for the clarification. I'm not sure if that is related. It could be that activate -t uses it for the implementation?

freebsd.org/releases/15.0R/relnotes/#ports Helloo! So I've been reading through this part of the release notes, but I have some questions. I took a look into my `/etc/pkg/FreeBSD.conf` and `/usr/local/etc/pkg/repos/FreeBSD.conf` in the first one I got `FreeBSD-ports` (enabled), `FreeBSD-ports-kmods` (enabled) and `FreeBSD-base` (disabled) in the second one I got `FreeBSD` (enabled) which I have configured to be latest

instead of quarterly. Since FreeBSD-ports and FreeBSD have the same url except FreeBSD-ports points to quarterly it should be clear that they have conflicts when I try to install a package in my case libebur128. So my solution would be to just disable FreeBSD-ports, since I want the latest repo. Would that be correct? And then, is this written somewhere in the Release Notes/Change Logs that this could be something some people

might need to fix by themself, since I couldn't find anything when I've been looking through them

lockna: you are allowed to fix it yourself

do you need guidance ?

mzar: No, thanks. I just disabled it with like it is described in the comments in /etc/FreeBSD.conf. I just wasn't sure if I just can disable the one in conflict with my latest repository or if it's giving me some hard time afterwards

no, now the packages will be updated to the versions existing in 'latest' repo

alright, thanks!

quarterly is snapshot of latest taken at the beginning of the quarter, so we'll have Q1 soon

yeah, i'm aware of that. Was just confused because after the update to 15.0 I had both actiavted, since a FreeBSD-ports got added without my doing

usually only critical or important updates are merged to 'quarterly'

no worries, it wasn't risky, maybe a bit messy

because the config for FreeBSD-base got added with 15.0, the repo for ports got renamed from just FreeBSD to FreeBSD-ports, as just FreeBSD could mean -base too (and would fit better for that), so you could just change your override for FreeBSD to FreeBSD-ports as the release notes say

because the config for FreeBSD-base got added with 15.0, the repo for ports got renamed from just FreeBSD to FreeBSD-ports, as just FreeBSD could mean -base too (and would fit better for that), so you could just change your override for FreeBSD to FreeBSD-ports as the release notes say