From nobody Mon Apr 21 01:25:16 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zgnk85J5Zz5sgCX for ; Mon, 21 Apr 2025 01:25:36 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zgnk73LCfz3tRG for ; Mon, 21 Apr 2025 01:25:34 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=CSgOqMI2; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745198718; bh=yMbtnEJ/kgLz5HU8MZz6ut43skRPJAPm0wQ6+KyaKd4=; h=Date:From:To:Subject; b=CSgOqMI2az2JBS6mDYhJzFXMHcbBhg9RSOcwLOKVb8nYtKPo/31G6uSIhpbmtyQVn SdJNb2mXZbCsdUdIAxVFvwhPL4wKCycSTY8eesiGUmZvMPkQ2ASs8Xuquc3H5ktoCM 8iQw33FbJdGfc2m3G7SAN+sv0pEvvwRLfh9ORCbdql9IVJrzn1i9DlqjBnW5sYllAG nKoMEc1Jkho5qQVxpfPDo0tF65QJXokXRKXrVIxrM5Xns+DWLJ1sRXOtul2izN3WhM DEq63Uce72L+pbBCxen13a2dC4fzl/yGNEf3PciCXCYarS4sq6jXQ5xVuBMzX6czj3 asdLPRSXH/09mKHwMQhRSDgdHAiLxF8saTlOygp2IFuz71duHOjgELZZlSHQpTMJiM l8/2VSV4j9d4t7u2SahgXgruyqxerSwqT2Uxiv2ijVZNj+XWxnpMzXTk8qGQbv19Xs fcKoijKF1WBkaKg7D/hkYppoxJlUfdkKfSH8jyZ/SJ4/lugo5hVhmx/YN45OMHbmEH Xi2n7KUj40pXfCKAj+uqwcTJhscNmt9yI5ynERu8p7y6h8JFfVyZ5jq3vvwJ96EVx0 eorXtX50V9jvRIYKbpWfo2RKl+uIhBht4kom+6FzLoansqIi4v4f6Xb/cx9aXc7YiK WYG1owDKbhoA1rYHjTyF3yAQ= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 369945A9371 for ; Mon, 21 Apr 2025 04:25:18 +0300 (EEST) Date: Mon, 21 Apr 2025 04:25:16 +0300 From: Sulev-Madis Silber To: freebsd-current Subject: zfs (?) issues? User-Agent: K-9 Mail for Android Message-ID: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [2.26 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.986]; NEURAL_SPAM_MEDIUM(0.98)[0.975]; NEURAL_HAM_SHORT(-0.93)[-0.926]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4Zgnk73LCfz3tRG X-Spamd-Bar: ++ i have long running issue in my 13=2E4 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=2E i had to turn watchd= og on because something a git pull on ports tree causes kernel to take 100%= of ram=2E it keeps killing userland off until it's just kernel running the= re happily=2E 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=2E if i happen to do too many src git pulls in= a row, they never actually "pull" anything=2E and / or clean my obj tree o= ut=2E i can't run buildworld anymore=2E 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 the= re's serious issue with fs=2E and how could it be fixed with waiting? it me= ans that some fs operations are still going on in background i have no idea what's happening here=2E zfs doesn't report any issues=2E n= or do storage=2E nothing was killed with out of memory but arc usage someho= w increased a lot=2E 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=2E how to test it=2E etc=2E and if this is fixed on 14, on stable, or o= n current=2E 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=2E or why does i= t behave like this=2E as opposed to usual low resource issues that just mea= n you need more time i mean it would be easy to add huge amounts of ram but people could also w= ant to use zfs in slightly less powerful embedded systems where lack of pow= er is expected but weird fails maybe not so is this a bug? a feature? something fixed? something that can't be fixe= d? what could be acceptable ram size? 8g? 16g? and why can't it just tune e= verything 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=2E it doesn't show any serious= io load=2E no cpu is taken=2E load is down=2E system is responsible it all feels like bug still i have wondered if this is second hand hw acting up but i checked and test= ed it as best as i could and why would it only bug out when i try more comp= lex things on zfs? i'm curious about using zfs on super low memory systems too, because it of= fers certain features=2E maybe we could fix this if whole issue is ram=2E o= r if it's elsewhere, maybe that too i don't know what to think of this all=2E esp the last issue=2E i'm not re= ally alone here with earlier issues but unsure