Oracle Blogs

This is partly true. CE has the "serial GC," yes, and no access to G1 GC by default. But Oracle GraalVM (formerly "GraalVM Enterprise Edition," which no longer exists) was released under a much less restrictive license:

https://blogs.oracle.com/java/post/graalvm-free-license

So, yes, GraalVM CE is slightly nerfed (the performance difference across all EE features is like 30% maximum, at peak, in limited circumstances). You also do not need to use GraalVM CE in as many places anymore, and Oracle GraalVM with G1 is a free download. Many free projects like Pkl use the full-blown VM.

https://www.graalvm.org/latest/reference-manual/native-image/optimizations-and-performance/MemoryManagement/

Serial GC is still very performant. It's great for things like command line tools which don't need a low-pause long-running GC like G1.

I wrote about this eons ago: https://cryptonector.com/2006/12/filesystem-i18n/ and https://cryptonector.com/2010/04/on-unicode-normalization-or-why-normalization-insensitivity-should-be-rule/ -- these might still be available on https://blogs.oracle.com/, though these are from my days at Sun.

TL;DR, basically, the lack of ability to tag strings in the system call API with codesets means that UTF-8 is the only plausible answer, and the ends (C library system call stubs, filesystems) have to apply whatever codeset conversions. But there's practically zero chance of C library system call stubs (and related functions) performing codeset conversions (can you imagine readdir(3) doing it?), which means that the only reasonable answer is to use UTF-8 locales and be done.

Even shorter: just use UTF-8 locales and be done.

Very nice work, and thanks for releasing under MIT.

Interesting that Backblaze decided to go with 17+3 configuration. As I read more on the topic, I realized I haven't quite wrapped my head around how data and parity are allocated across symbols, stripes, and disks, and how all that impacts degraded read performance, but at first glance I would assume 17+3 would have a pretty terrible degraded read performance.

Another great read if you're interested in home brew RAID or using parity is Plank's paper "Tutorial on Reed-Solomon Coding for Fault-Tolerance in RAID-like Systems". [1]

I found that gem reading Adam's blog on implementing triple parity RAID in ZFS. [2]

[1] - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.7089&rep=rep1&type=pdf

[2] - https://blogs.oracle.com/ahl/entry/triple_parity_raid_z

This is tricky, because it's a class of problem that you need to understand exists in order to seek out the relevant information. Once you know what to look for, it's easy to find guidance - even from Oracle themselves [0]

A lot of us have "learned the hard way," as it sounds like Linus himself eventually did. I think this highlights an issue with the "learn through youtube video" approach. An internet celebrity may acquire enough knowledge to do accessible demonstrations, presenting totally valid, useful, and correct information in them, and still miss crucial "unknown unknowns" that they simply hadn't encountered in their own research.

It's hard to know what to recommend for a class of issue you aren't even aware of!

[0] https://blogs.oracle.com/oracle-systems/post/disk-scrub-why-and-when

Yeah that was one of the gotchas in the story at https://blogs.oracle.com/linux/post/attack-of-the-cosmic-rays -- MAYBE it was a bit flip due to a cosmic ray, or MAYBE it was a bit flip due to another layer of the system that makes RAM chips store and retrieve data.

I like the idea of a physicist who thinks about this and says - "well, why should we shrug and say 'maybe it was a cosmic ray?' Surely we can test this! Let's put the computer in a lead-lined enclosure and benchmark the memory failure rate and see if it changes", or whatever.

That's a great extension of the classic computer-hacker view that "of course we can understand why this bug happened, we don't have to shrug and say it segfaults until we restart sometimes, we can just dig some more." How far can you go?

I've seen this repeated a lot, but have not had quite the same experience with "permanent" performance degradation. Especially if I eventually expand the pool with another vdev. Not sure about ZFSonLinux, but:

1) Having a ZIL helps with this, and in general.
2) ZFS changes strategy depending on how full it is, it spends more time avoiding further fragmentation rather than grabbing the first empty slot. This hit would go away if you get the free space back up.
3) Finally, there is a way[1] to have ZFS keep all the info it needs in RAM to greatly alleviate the times when it starts hunting harder to prevent more fragmentation. It looks like the RAM requirements are 32GB/1PB... so not too bad IMO.

[1] https://blogs.oracle.com/bonwick/entry/space_maps