I’m using a Truenas Mini R and see this in both 24.10 and 25.04
24.10
25.04
1 Like
So by my reckoning, an extra 1GiB more ZFS cache. That would be a small but worthwile win no?
Not necessaily at the same stage/load… What we’re looking at is that ARC uses more than 50% RAM, which earlier releases of SCALE could not.
1 Like
So this is kind of why I have stopped submitting tickets, they keep getting closed out. 
Does it only happen in a setup that uses LACP and VLANs in such a way?
Not, it is not limited to these conditions. Something similar happened to me on Eel with docker on setup without bonds or vlans.
Testing and saving changes in TrueNAS UI after I modified only interface description destroyed br-x interface used by docker network while leaving said network running. This sent attached containers into peculiar state where they couldn’t be reached outside and couldn’t restart either because their binding ports were still busy.
Maybe significant detail that this bridge was created with docker network create and used as external: true in compose, I didn’t dig much into that.
Nope, basic interfaces, it’s a problem across the board…
In that case, if you haven’t given up, posting the bug report with a simplified scenario may see better success. As simplified as can be while still triggering the issue.
1 Like
My TrueNAS has been using more than half of ARC since EE.
EE (beta, rc?) had the issue that would result in swap being filled despite plenty of available RAM due to some changes (Linux kernel?) with the end result being an unresponsive system. The temp fix I used was to disable swap. I think some others were just reducing the ARC size. Perhaps this was still configured until you upgraded?
This screenshot doesn’t have the version, but I uploaded it 2024:
It did, and I stuck with FreeNAS/Core until I installed an HBA that wasn’t supported 
1 Like
I seem to remember some release(s) of Truenas setting the max arc cache to about 50% of ram…because some tuning guides had some overrides to change that. Seems like the devs knew something was fundamentally flawed and eventually fixed it because I don’t think that choke valve is there anymore.
Yes, that was SCALE pre-24.04.
That was the first release or two of Dragonfish.
I know I didn’t manually change any tunables when I upgraded 24.10 → 25.04. I’m 99% sure I didn’t have any in there previously, but I’m not about to boot back into 24.10 to check. But I never saw more than half of RAM used as ARC in 24.10; now I do. A good change in my book.
3 Likes
Time flies. Didn’t realize it was that long ago, but that’s the only thing I can think of.
Definitely was using more than 50% on my EE.
Agreed it’s a welcome change.
So I clicked “Update all apps” for the first time.
"[EFAULT] In order to upgrade an app, it must not be in stopped state"
Why not just launch that app and upgrade it, instead of telling me that error, having me start it and then click update again?
3 Likes
Yea, the work to make Linux have more or less the same ARC functionality that BSD had was completed a while back. It’s been pretty quiet on that front ever since.
1 Like
Can you write a test plan for all the cases for why an App is stopped?
We try to avoid handing people loaded guns without them noticing…
I dont understand your reply which sounds kinda condescending.
I clicked on a WebUI element with the name “Update All Apps”.
So my expectation was that it would… you know… update all apps?
I think that expectation was reasonable.
I did not expect it to update just the apps that are running, as that is not what the name of that button indicates.
If I would only want to update certain apps, then why would I press the “Update ALL apps” button?
If you want to avoid handing people “loaded guns” then you might want to remove the “update all apps” button, as updating an app that is currently running could be equally (or actually even more) catastrophic than one that is in a stopped state - that is if I dont know what I am doing.
That said if I dont know what I am doing then there are many other options in TrueNas that can do much more harm than “Update All Apps”. So… I remain confused by your reply.
If this is indeed such a concern, the WebUI could be so kind and ask if I want to also update the stopped apps as well.
2 Likes
Sorry if you thought it was condescending… I was just trying to point out that there many potential risks which are very hard to quantify.
Apps can be stopped because:
They have a bug
They are a security risk
They are corrupting data
They are not needed
They fail and require restarting
So, without that information it is VERY UNSAFE to restart an App automatically.
The UI lets you choose specific Apps to update. You can also restart or delete the App that is blocking updates.
So, yes, we opted for safety and not convenience. In our business, we have to do that. Customers don’t pay for extra risk.
3 Likes
I agree with what you’re saying but I also see the frustration as whenever I have updated all apps, the first thing it does with apps that are started is stop them and those that are stopped, starts them and then stops them. So it seems like where an app that isn’t started is updated, it is immediately started, then stopped prior to updating. If that is the case, why the need for starting the apps at all when updating?
2 Likes