121–130 of 172 posts
Earlier quoted context omitted.
Which mcu are you using ? The possibility of noise becoming a flash command is practically 0. Also too much noise will more importantly corrupt you ram. Flash can be sensitive to noise and that can cause bit flips.
>The problem also happened exceedingly rarely -- we needed about 100 of these devices to run constantly a certain operation and it took us to wait for about a week until one of these devices died That's one failure per 16,800 hours, or 700 days. That's pretty goddamn rare.
Earlier quoted context omitted.
Using it through something like TrueNAS with sensible defaults is probably a better idea for the average person than trying to roll their own deployment, no?
Im not sure running TrueNAS counts as learning ZFS, which I think is GP's point. If you want to use ZFS, then TrueNAS with sensible defaults is a great way to go. If you want to learn ZFS enough to roll your own deployment, change the configuration correctly and understand the changes you make then don't start with TrueNAS, and definitely don't listen to the TrueNAS community. Or at least, that's how I read the GP co…
I know, I was doing just that 5+ years ago.
Commercial storage vendors aren't really any different. Mostly the biggest difference here is they offer a very limited subset of hardware and disk configurations and tend to iterate over that very small configuration space. Step outside of that config space and they won't have much insight.
This remind me of the earlier days of Mac vs PC. Mac tended to have a very small hardware set of supported devices, and in many ways helped stability. PC supported pretty much anything you threw at it, which commonly had issues with crappy drivers and untested interactions.
Earlier quoted context omitted.
>> When the voltage is low enough to confuse communication signals, but not low enough to prevent destructive events from occurring. I heard from a coworker that an older version of the product had bumped from a 16MHz chip to 20MHz to run more code. Chip supplier screened parts for the higher speed, but didn't cover higher speed across the normal voltage range. When supply dipped (within the old spec) switching speed…
I wonder if anyone else instantly gets a visual after reading your story: “Business woman on plane: Are there a lot of these kinds of accidents? Narrator: You wouldn't believe. Business woman on plane: Which car company do you work for? Narrator: A major one.”
Earlier quoted context omitted.
A more "correct" fix has been posted https://github.com/openzfs/zfs/pull/15615
Neither of these fixes are great because neither of them include tests. This is a dataloss bug in a filesystem, no existing test covered it, and no new tests were added to demonstrate the efficacy of the supposed fix or prevent regressions.
OpenZFS is on an exceedingly short list of software in my life that I actually trust to do what it's supposed to. Where most software just up and falls over every so often, ZFS chugs along, day in and day out. Then ZFS has one bug and everyone starts acting like the sky is falling. And sure, it was a bad bug, but you had to be pretty unlucky to trigger it, and it was present in ZFS for all of a month. Meanwhile, peop…
Block cloning happened to expose this bug easier, but it seems like this bug might actually date back to the very beginning of ZFS with Sun, with the opportunities to trigger it being so rare, that nobody had noticed until now. I suppose it's still a bad bug, but it goes to show that file systems are complicated beasts, practically impossible to test all the ways they can be put through the wringer, and bugs like thi…
Looks like you might be right about that. The oldest commit referenced in the fix [0] was from 2006[1], which was ~5 months after Sun released ZFS.
Glad this is fixed!
[0] https://github.com/openzfs/zfs/pull/15571
[1] https://github.com/illumos/illumos-gate/commit/c543ec060d
Earlier quoted context omitted.
For Postgres just follow the original doc: https://openzfs.github.io/openzfs-docs/Performance%20and%20T... compression=lz4 recordsize=32K In postgres -> full_page_writes=off
But also experiment with recordsizes of 8k and 16k. The larger the recordsize, the more potential compression you get, which may be offset by additional delay caused by read/modify/write of the larger record (i.e. reading/writing 32k instead of 8k or 16k).
Earlier quoted context omitted.
I heard the story decades ago, and the problem had been fixed some years prior to that. There are undoubtedly hundreds of similar issues across the tech industry, most get quietly fixed before much damage is done. I only tell the story because it's an example of how obscure details come together in unexpected ways to cause failures. That happens everywhere.
And how brittle the borders we programmers see a strict, as a branching condition, "this should never happen". But in hardware, things are different. How do you even protect against such a thing you just described? Put the airbag on a diffent microprocessor?
I don't know about BTRFS, but with ZFS there's a lot of bad information and assumptions floating around. It's one of my favorite topics to ask AI about because it shows the obvious deficiencies in AI as it regurgitates all the bad info. So when you go to the issue tracker, it seems plausible to me that you're going to find issues where the devs can't explain what's happening because the user(s) might be doing somethi…
No, that is not plausible. It's a filesystem. Behaviour in all cases for a filesystem should be predictable. There are zero things a user should be able to do that would make a filesystem non deterministic.
Earlier quoted context omitted.
And how brittle the borders we programmers see a strict, as a branching condition, "this should never happen". But in hardware, things are different. How do you even protect against such a thing you just described? Put the airbag on a diffent microprocessor?
Maybe put some code directly before bag deployment code that disarms the system. So even if the execution reaches it directly through the branches, nothing will happen