Hi, First, instead of writing "it gives vague errors", it really helps others on this list if you can copy-paste the errors into your email.
Second, as far as I can see FreeBSD 13.4 uses OpenZFS 2.1.14. FreeBSD 14 uses OpenZFS 2.2.X which has bugfixes and improved tuning, although I cannot claim that will fix your issues. What you can try is to limit the growth of the ARC. Set "sysctl vfs.zfs.arc_max=1073741824" or add this to /etc/sysctl.conf to set the value at boot. This will limit the ARC to 1GB. I used similar settings on small machines without really noticing a speed difference while usability increased. You can play a bit with the value. Maybe 512MB will be even enough for your use case. NB: sysctl vfs.zfs.arc_max was renamed to vfs.zfs.arc.max with arc_max as a legacy alias, but I don't know if that already happened in 13.4. Another thing to check is the usage of tmpfs. If you don't restrict the max size of a tmpfs filesystem it will compete for memory. Although this will also show an increase in swap usage. Regards, Ronald. Van: Sulev-Madis Silber <freebsd-current-freebsd-org...@ketas.si.pri.ee> Datum: maandag, 21 april 2025 03:25 Aan: freebsd-current <freebsd-current@freebsd.org> Onderwerp: zfs (?) issues?
i have long running issue in my 13.4 box (amd64) others don't get it at all and only suggest adding more than 4g ram it manifests as some mmap or other problems i don't really get basically unrestricted git consumes all the memory. i had to turn watchdog on because something a git pull on ports tree causes kernel to take 100% of ram. it keeps killing userland off until it's just kernel running there happily. it never panics and killing off userland obviously makes the problem disappear and nothing will do any fs operations anymore dovecot without tuning or with some tuning tended to do this too what is it? now i noticed another issue. if i happen to do too many src git pulls in a row, they never actually "pull" anything. and / or clean my obj tree out. i can't run buildworld anymore. it gives vague errors if i wait a little before starting buildworld, it always works what could possibly happening here? the way the buildworld fails means there's serious issue with fs. and how could it be fixed with waiting? it means that some fs operations are still going on in background i have no idea what's happening here. zfs doesn't report any issues. nor do storage. nothing was killed with out of memory but arc usage somehow increased a lot. and it's compression ratio went weirdly high, like ~22:1 or so i don't know if it's acceptable zfs behaviour if it runs low on memory or not. how to test it. etc. and if this is fixed on 14, on stable, or on current. i don't have enough hw to test it on all i have done other stuff on that box that might also improper for amoung of ram i have there but then it's just slow, nothing fails like this unsure how this could be fixed or tuned or something else. or why does it behave like this. as opposed to usual low resource issues that just mean you need more time i mean it would be easy to add huge amounts of ram but people could also want to use zfs in slightly less powerful embedded systems where lack of power is expected but weird fails maybe not so is this a bug? a feature? something fixed? something that can't be fixed? what could be acceptable ram size? 8g? 16g? and why can't it just tune everything down and become slower as expected i tried to look up on any openzfs related bugs but zfs is huge and i'm not fs expert either i also don't know what happens while i wait. it doesn't show any serious io load. no cpu is taken. load is down. system is responsible it all feels like bug still i have wondered if this is second hand hw acting up but i checked and tested it as best as i could and why would it only bug out when i try more complex things on zfs? i'm curious about using zfs on super low memory systems too, because it offers certain features. maybe we could fix this if whole issue is ram. or if it's elsewhere, maybe that too i don't know what to think of this all. esp the last issue. i'm not really alone here with earlier issues but unsure
