00:20:39 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 00:20:41 people are away from their computers and stuff is slower 01:38:00 what causes state-insert (failures) in the output of pfctl -si? (state-insert state insertion failure) 01:49:56 kerneldove_: a full state table perhaps; do you have frequent failures? 01:51:26 no state table isn't full. i don't get any 'memory' errors fwiw 01:51:43 just state-insert and state-mismatch but only a few of those 01:52:14 highest i've seen current entries is like 800k and my limit is upped to 1.2M 01:52:45 300k searches/s 01:53:00 1 state-insert per sec 01:53:53 if you really want to know what causes it, the best way would be to read the source for it 10:13:10 or ask on pf@, which probably has more pf experts than this channel 11:47:59 Is there a way I can monitor the zfs memory consumption on 15.0? 11:49:57 Liaf: top(1), sysctls under vfs.zfs 11:55:38 I realize my question was kinda silly :-D 12:13:47 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. 12:14:29 all memory which is Inact, Buf, Free or is used by ARC is available for use by applications 12:16:36 So with ARC: 3000M Total that would mean this is "free" for applications? 12:17:14 yes, zfs will release it if an application needs more memory 12:19:31 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? 12:20:03 the memory consumption is what it is -- this is no different from UFS, which also releases its cache memory when applications use it 12:20:13 and yes, you can use ZFS with 2GB RAM 12:21:52 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 :-) 12:23:13 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 12:33:19 that's allowed, no worries Liaf 12:33:42 Okay, I will just play around with my two test systems for now :-) 12:33:48 Thanks a lot for the input :-) 12:36:38 Liaf: it's worth setting vfs.zfs.arc_max="768M" or similiar value, dependent on your workload, in loader.conf 12:44:16 at some point (iirc <1G RAM) you should manually tune memory settings of zfs 15:26:44 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 :-) 15:29:52 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. 16:10:57 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 16:11:58 speaking of which 16:12:52 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? 16:39:39 futune_ there should be no difference, that code does not depend on firmware type 16:41:32 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... 16:41:42 but it would be lovely if it works 17:03:59 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? 17:08:24 onlyoffice doesn't print on Fridays 17:14:36 lts, yes, unless you prevent them to tcpdump (no bpf interface) 17:16:29 Ah, compensating control 17:16:37 Thanks, I can be at peace now 17:17:27 lts, by default there's no bpf interface in devfs.rules for jails 17:17:50 Yup, understood 17:26:03 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 17:31:59 ivy: thank you. I figured that it's also stable with less memory :-) 17:34:27 tercaL: sure, but not in one go 17:35:17 futune_: you are probably thinking about nextboot facility, not zfs one 17:35:35 istr nextboot had issues with uefi boot back then 17:38:01 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 17:38:46 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 17:39:32 ivy: ah right, well I dont ever remember having issues with zfs even on low memory devices 17:40:11 ivy, I always heard you want 1GB per TB of raw disk space. 17:42:31 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 17:43:28 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 17:45:53 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 17:46:13 s/no /no point/ 17:47:56 (well, maybe there is nowadays with the price of memory, but...) 17:49:43 the joys of using old devices :p 17:49:47 cheap memoryt 17:49:49 Same here, but only because ARC is great and I have spare DDR available. Otherwise it would run happily with 8GB or much less 17:49:53 just harvest it from some shit lying around 17:51:13 Looks like my backup server with roughly that amount of (raw) storage uses a whopping 1106MB of memory at the moment 17:51:42 Probably because it runs some bhyve vms too 17:52:08 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 17:57:17 +1 ivy 17:57:47 I did always find it stupid how people say "Oh I need 128GB of memory for my storage server of 2x4TB HDDs" 17:58:10 I think a lot of it is just because they can, not so much because you *need* it 17:58:22 but memory is not some magically thing which instantly makes things faster by increasing the amount of it 17:59:02 my home fileserver has 64TB raw disk and 32GB RAM, but that's because i'm poor and it works fine as is :-) 18:08:59 Huh, I thought I asked it, but can't find it in my logs. 18:09:11 I was wondering, what's the status of armv7 support w.r.t. future FreeBSD now? 18:09:46 (ah, I found it now ... I asked in #freebsd-ports by accident) 18:10:16 (but didn't get a reply anyway) 18:10:26 What I mean is, is it still going to be removed post-15? 18:10:30 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. 18:10:41 (or 32-bit RISC-V, are there any plans of adding support for it at any point?) 18:10:46 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 18:10:54 DarkUranium: 32-bit riscv will almost certainly never be supported 18:11:34 DarkUranium: if you have a use-case for armv7, consider posting on arch@ in support of keeping it 18:11:37 Fair, thanks. I guess I better look towards NetBSD for those platforms ^^ 18:11:47 ivy: not a strong one, TBH; I'm just a hobbyist. 18:15:04 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... 18:31:03 cyric, yeah, I was only talking about the -t flag for bectl activate, aka nextboot 18:31:21 do you know if the uefi issues with that have been resolved now? 18:44:34 futune_: i mean the nextboot(8) which is completely unrelated to zfs 18:48:04 cyric, thanks for the clarification. I'm not sure if that is related. It could be that activate -t uses it for the implementation? 23:42:10 https://www.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 23:42:10 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 23:42:11 might need to fix by themself, since I couldn't find anything when I've been looking through them 23:45:52 lockna: you are allowed to fix it yourself 23:46:02 do you need guidance ? 23:47:48 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 23:48:59 no, now the packages will be updated to the versions existing in 'latest' repo 23:49:13 alright, thanks! 23:49:58 quarterly is snapshot of latest taken at the beginning of the quarter, so we'll have Q1 soon 23:50:41 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 23:50:48 usually only critical or important updates are merged to 'quarterly' 23:51:27 no worries, it wasn't risky, maybe a bit messy 23:54:50 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 23:56:42 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