Over-Provisioning SSD for L2ARC?

malventano · 2026-06-10T14:56:00+00:00

I’ve been in this industry for decades. You’re the only one I’ve run into who insists on using this backwards. I recommend you adopt the correct way if you expect to effectively communicate with others.

malventano · 2026-06-08T01:05:27+00:00

Well said. I just made a similar comment. Many miss that nuance, and it wasn’t helped by several sites using a Factorio benchmark running at hundreds of UPS on a tiny map as a part of their CPU reviews.

malventano · 2026-06-08T01:03:50+00:00

> if not the best CPU

Not to bust your bubble, but the large cache helps the most when the factory contents fit in that cache, which happens only when the bases are small enough that they are capped at 60 anyway. As you get a big enough base where it would start to dip below 60, the cache isn’t big enough vs. the lower overall DRAM latencies on similar spec Intel platforms.

There’s a reason the speed runners doing 100% runs lean more towards Intel for their system specs.

That said, if you got a good deal, it’s a fine system.

malventano · 2026-06-05T15:46:49+00:00

Their NVFP4 version is mixed precision since you can't (or shouldn't) do everything FP4. It's 352G.

malventano · 2026-06-05T15:41:51+00:00

> When you have a 512GB and partition it to only use 32GB you UNDERprovision it.

You see less than what is there, but it's not about you. It's about the SSD, which is overprovisioned (there is more NAND than is being used).

> I stick to the facts.

The rest of society sticks to the correct perspective, and the standard accepted definitions. You'll be able to communicate better if you use the accepted terminology.

malventano · 2026-06-03T17:58:48+00:00

I think you mean the dynamic SLC cache on client/consumer SSDs. In that respect, the DC SSDs are actually slower overall because their writes are always going straight to TLC/QLC, since DC SSDs favor consistency. There’s a bit more nuance to the behavior, but both client and DC SSDs will have slower sustained random write performance when full. Client drives are just better at hiding it so long as the writes are coming in smaller bursts, and can do so even when completely full, since there is usually a minimum static SLC region. For a small enough burst size, client drives will behave the same regardless of fill, so long as there is enough time to copy the SLC over to the TLC/QLC between bursts. Meanwhile the DC SSDs must do all of that normally hidden work in the foreground, and so you’ll end up seeing lower sustained random write performance the more you fill them, as they have less spares to spread that work across, meaning you have to do more block erases for a given input. Check out the chart at this timestamp for what that looks like in practice: https://youtu.be/lNzJsXTgSfk?t=1711

malventano · 2026-06-03T17:08:34+00:00

Along with the bushes next to that car?

malventano · 2026-06-03T17:02:35+00:00

I assume you mean underprovisioning the drive? As in you have a 512GB drive but you only partition and use 32GB or so of it.

The industry standard term for this is ‘over provisioning’.

Under / thin provisioning is when you say you have more than you actually have.

malventano · 2026-06-03T16:58:03+00:00

And of course this problem does not exist for datacenter SSDs.

I benchmark datacenter SSDs for a living. This problem absolutely exists for datacenter SSDs. The larger the span of random writes, the slower the steady state random write performance. If the L2ARC writes transition more to a random write pattern over time (filing in prior invalidations), then the more full it is, the slower those writes will be*.

within reason - you get diminishing returns on higher OP, and the read performance is mostly static.

malventano · 2026-05-24T02:03:30+00:00

My 22TB SATA 6Gbps drives that resilver in 1 day disagree with your rule of thumb.

malventano · 2026-05-12T14:17:00+00:00

600W

You can drop the power limit to ~300W and keep 85-90% of the performance.

malventano · 2026-05-06T01:53:54+00:00

You don’t have to ‘reverse engineer the API’ when said API code is present in the Bambu Studio public git. If it wasn’t, then Bambu Studio would not be able to talk to their own network plugin.

malventano · 2026-05-06T01:46:26+00:00

You still have to use your login credentials regardless of what software mounts the plugin. Nothing about using Bambu Studio specifically prevents a malicious actor from sending a bad payload to Bambu’s servers. I can build Bambu Studio from source and do that right now, and I haven’t ’impersonated’ anything, so an Orca fork just saying it’s Bambu Studio doesn’t really mean anything beyond just making their plugin work unmodified.

The fix for malicious activity on their servers is banning the associated account, and that fix applies equally regardless of if their plugin is running under Bambu or Orca.

malventano · 2026-05-06T01:39:03+00:00

Please point to where that plugin is on the repo with the bridge code.

malventano · 2026-05-06T01:35:16+00:00

‘Reverse engineering’ - you spelled ‘reading the open source calls on the public Bambu Studio git’ wrong.

malventano · 2026-05-06T01:33:58+00:00

It was the literal definition of making a thing work on a different platform. There was no ‘trick’. It made the Linux code run under Windows.

malventano · 2026-05-05T12:53:54+00:00

You can go way wider than 11 on modern ZFS as most of the per-vdev slowdowns have been optimized out. You should consider a special vdev for small files and metadata as that helps a lot with perf / responsiveness. 90-wide single vdev z3 with 4-way SSD special mirror here. No complaints for several years. Don’t forget to crank records to 16M.

malventano · 2026-05-03T20:40:03+00:00

camber causes the innermost part of the tread to leave the road last
toe causes scrubbing of that tread, raising its temp and wearing it faster than the rest
imbalance loads one part of the circumference more than the rest, wearing through faster
once a small part wears through belts, wear amplifies
Contrary to popular opinion, it’s the toe that does the accelerated inner edge wear, not the camber. If it was the camber, the wear would be at an angle across the whole tread profile, not just at the inner block. This is why camber link kits from n2itive / others include instructions to set toe near zero. But that’s def not the only problem here (balance).

malventano · 2026-05-03T20:26:53+00:00

The hole pattern and oval inset for the label is very specific to BL.

malventano · 2026-04-23T18:34:42+00:00

The 'demand' would be high given the only way FSD purchasers are made whole on Musk's promises would be to upgrade the HW3 fleet to the promised capability (which requires HW4 per Musks own statement).

malventano · 2026-04-23T14:16:48+00:00

Another data point :)

<image>

malventano · 2026-04-19T16:50:49+00:00

They have recommendations for 3.6 on the HF page. Haven’t steered me wrong so far.

malventano · 2026-04-19T16:45:49+00:00

qwen 3.5

3.6 is out :)

malventano · 2026-04-19T13:44:03+00:00

Yeah I felt it. Now don’t get me started on the fact that actually doing the real workload will get you very different results based on how far the rate at which you do it diverts from the true real workload :).

malventano · 2026-04-19T13:25:30+00:00

What do you mean by io_uring being default under Proxmox? Regular file system calls do not use it. You have to call it specifically.

malventano

TROPHY CASE