From Newsgroup: muc.lists.freebsd.stable


On September 28, 2025 5:58:52 PM GMT+03:00, Warner Losh <imp@bsdimp.com> wrote: >On Sun, Sep 28, 2025, 4:47rC>AM Graham Perrin <grahamperrin@gmail.com> wrote:

Follow-up to <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287719#c6> >>
Good news.

2048 MB is sufficient with root-on-ZFS for an ordinary installation
(more than base, less than all of FreeBSD-base) of 15.0-ALPHA4
plus these five non-base packages, some of which are meta:

kde plasma6-sddm-kcm sddm virtualbox-guest-additions xorg

Beyond initial installations: with 4 G swap enabled, I repeatedly
tested forced reinstallation of all packages,

pkg upgrade -fUy

1077 packages, 1886 steps. Success.

----

With swap disabled, which I would not recommend:

- reinstallation failed, switch from ttyv1 to ttyv2 was
impossible, and so on, so I attempted a shut down
<https://i.imgur.com/RftLGMu.png>

- shut down failed

- following a forced stop of the computer, SDDM and the
desktop environment were unsable (pkg issue 2441,
second incident this morning).

It's big enough to install.. but i have lxte + terminal + firefox with 4
tabs open and I routinely run out of memory and swap heavily. I have a 4GB >Chromebook.

So one can run in 128MB for light tasks and careful kernel tuning, 512MB is
a more realistic minimum since it lets you install and update. But for X
it's flipped: you need 2G to install but closer to 4G or 8G to run a >complete, but on the lean side, X11 system.

Warner

you know, i won't believe this until i get my willpower together and build new machines so i could stop fingering my headless machines via my 12g ram 8g swap phone which somehow uses it all to do nothing (and where variant of ff uses 1.1g to display 5 tabs)
but, 2g to *install*? pkg needs 2g now? how? i regularly use pkg to manage large packages on low end systems and don't notice it being largest consumer on the system
and 8g to run x? a lean x?
and ff now needs 1g per 1 tab? have to check that too, mozilla could deserve few slaps
maybe i try before physical hw is ready because those are like ram salesman numbers
those are high even for zfs
i hope this didn't cause any less resourceful hw owners to lose interest
that gets me curious and damn if i can still get things up like few years ago with similar resources... eh
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable


On October 1, 2025 12:58:05 AM GMT+03:00, Rick Macklem <rick.macklem@gmail.com> wrote:

On Tue, Sep 30, 2025 at 1:18rC>PM Warner Losh <imp@bsdimp.com> wrote:

On Tue, Sep 30, 2025 at 2:03rC>PM Rick Macklem <rick.macklem@gmail.com> wrote:

On Tue, Sep 30, 2025 at 12:50rC>PM Warner Losh <imp@bsdimp.com> wrote:

Yea, I've not seen that to be the case. ZFS isn't that big of a memory hog these days... There are times you do need to tune the arc, but they are the exception, not the rule.

Unfortunately, using ZFS as an NFS server seems to be an exception.
Peter Errikson still uses 13.5 on his servers, since he doesn't find 14.n >>> stable enough.
There is this email thread:
https://lists.freebsd.org/archives/freebsd-stable/2025-September/003126.html

OK. Since I no longer do NFS, I've not hit that....

I didn't figure you had hit it.
I was hoping that you (or someone else reading this) might
know someone willing to tackle the problem?

rick

I'd like to see this resolved, but I don't know enough about VM or
ZFS's arc code
and I have miniscule hardware, so I cannot replicate it.

i've hit it. or at that's at least i assume (= makes ass out of u and me)
i'm also 13.5. i'm 4g ram. but he can do it in >=128g
same thing. arc is low, wired high, kernel kills procs. caused by apperant mmap, now scrub
that thing has one 4t single disk pool and two 2-disk mirrors, 160g and 12t
i tried to choke git and dovecot and it worked. can't limit scrub
i've battled it for years!!!
btw, i've ran zfs in 512m in 2015. worked. buildworld. scrub. 40g pool 1 disk. why 512m is because i had 1g and i skipped memtest86+ which didn't boot from usb and later i found, when booting off actual cd or dos or whatever i used then to find out that one 512m module is bust
that all worked until hdd/mobo/psu/... went balls up. hdd corrupted data in fs (i assumed ram), later apparently failed, mobo had caps visibly bulged and even bust (wasn't there). so i'm in no way unknown to running low resc hw zfs. or stupidly bad hw maybe. but it somehow worked better than now. how can it be?
but zfs has gotten better now. i had c2q, rw was 40mb/s. now rw on zfs is proper >=200mb/s on c2d
things have improved but i wish i could have fix to this cursed wired full problem
btw, if you think that low ram and cpu is a throwaway second hand hw only, then no. nowadays you have embedded systems like that. and they could benefit from checksums, compression or copies=3 (wild guess to "fix" future flash block failures) the zfs brings
yeah, i bet sun's engineers are rolling in their beds and graves, "zfs runs where?!", "they crastrated it!!!"
but there's a reason why that's such a good fs design that noone has replicated yet. at least together with volume manager. which i think is right idea. fs should have direct control to devices because only fs knows where the actual data is
but how to fix memory issues i have no idea. i've tried asking everywhere. i don't think this is low ram either. it's a memory utilization, not amount, issue. you can run out of 2t too i'm sure
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2