Scale memory utilization

[jgreco]

This also sounds Luke setting max ARC size manually is a bad idea because there might be some memory fragmentation(sounds serious?).

Pretty clear that 50% is just some relatively safe number someone pulled out of an orifice. I expect the problem is that on a small memory system, there's a lot more stress and also a lot of relatively foolish users who will try to squeeze the hell out of it. There shouldn't be a problem on a larger memory system.

I would assume they intend ro fix memory allocation/fragmentation/reporting instead of just increasing max_arc. Because the latter of which may cause instability when unintentionally overcommiting memory.

That's going to be tricky without some cooperation from Linus. Most memory allocation is pretty complicated in modern systems, even Linux.

 

[winnielinnie]

If I didn't know any better, I'd have thought that @jgreco got bullied by a bunch of penguins during an escapade in Antarctica. Ever since that traumatic experience, he's had this seething hatred and vendetta against all things related to penguins.

 

[NugentS]

If I didn't know any better, I'd have thought that @jgreco got bullied by a bunch of penguins during an escapade in Antarctica. Ever since that traumatic experience, he's had this seething hatred and vendetta against all things related to penguins.

Or he was brought up in a school run by nuns with the same result

 

[jgreco]

I'd have thought that @jgreco got bullied by a bunch of penguins during an escapade in Antarctica.

I tried roast penguin last week and it gave me diarrhea and terrible flatulence. The skies turned orange and people said the air quality was toxic.

 

[jgreco]

I suppose that's going to age terribly so I should probably make a note that Canadian wildfires have left the US eastern coast in orange.

 

[asap2go]

I suppose that's going to age terribly so I should probably make a note that Canadian wildfires have left the US eastern coast in orange.

Looks like international Ubuntu day :)

 

[jgreco]

Touche'

 

[Arwen]

Gee, someone mentioned the B word, (BTRFS), and NOT that it was implemented first at Oracle;
Wikipedia - BTRFS - History

So, does this mean BTRFS is also contaminated?
Not according to Linux people!!!

The big differences:

1. GPL license compared to CDDL
2. Designed for Linux kernel only, (and kernel drivers are part of the Linux kernel source code)

Their are a few other OSes that have support for BTRFS, an open source version of the MS-Windows comes to mind, though I don't remember the details. But, for practical sake, BTRFS is a one OS file system. Unlike OpenZFS, which now exists on 6 OSes... I will leave it to the reader to get the list if desired.

 

[Ericloewe]

You know, I'd forgotten about that part. Funny how major patches from Oracle are okay when protected by their Cope License.

Please spit your venom. Don't let it consume your from inside.

So as to not derail this, I'll just say: "Compose File Specification", more properly described as "Compose File Anarchy".

 

[morganL]

"For Linux, its the safe margin for ARC due to fragmentation on SLUB allocator.
We're treating it as a bug and plan to fix or mitigate it....
Planning to fix in Cobia."

This also sounds Luke setting max ARC size manually is a bad idea because there might be some memory fragmentation(sounds serious?). Thank you for the info!
Hope Morgan can tell what Cobia means.

Its complex and still under investigation. We have assigned a guy with strong Linux skills to review.

My current take is that users who make use of Apps and VMs are getting the benefits of their RAM. No major issues.
Users with a primary storage-only workload need a better configuration option.. 75-80% would be a major improvement.
We shouldn't let the desire to be perfect delay the need to be good.

Does that align with the views here?

 

[asap2go]

Its complex and still under investigation. We have assigned a guy with strong Linux skills to review.

My current take is that users who make use of Apps and VMs are getting the benefits of their RAM. No major issues.
Users with a primary storage-only workload need a better configuration option.. 75-80% would be a major improvement.
We shouldn't let the desire to be perfect delay the need to be good.

Does that align with the views here?

For me personally that would be alright as it is the ratio I am going to split memory anyway.
As long as its stable that'd be awesome.

 

[danb35]

My current take is that users who make use of Apps and VMs are getting the benefits of their RAM.

I use (well, used, until they completely stopped working almost a week ago) lots of apps--over 20 of them--and my server was still sitting with over 40 GB of RAM free according to the TrueNAS dashboard. My ARC hit ratio was still well over 90%, so I guess it isn't that critical of a problem, but that's still about a third of my RAM being wasted.

 

[Cytomax]

Is there a bug for this problem that i can follow to see when it gets fixed?
Is there a planned release date for Cobia?

 

[morganL]

Is there a bug for this problem that i can follow to see when it gets fixed?
Is there a planned release date for Cobia?

There are a coupl of bug IDs.

Log in with Atlassian account

Log in to Jira, Confluence, and all other Atlassian Cloud products here. Not an Atlassian user? Sign up for free.

ixsystems.atlassian.net

Cobia is planned for Q4.

 

[Cytomax]

ty for the reply when i click on your link this is where it takes me
and when i search for NAS-117879
it doesnt find anything

 

[morganL]

ty for the reply when i click on your link this is where it takes me
and when i search for NAS-117879
it doesnt find anything

This one might be better:

[NAS-112185] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

There is no target date until we have identified a resolution. Its still being explored.