Reading the comment re: what the FS dev teams should do by someone who I bet didn't pay a dime for the software just upsets me.
[flagged]
In OpenZFS and Btrfs, everyone was just guessing
61–70 of 172 posts
Re: In OpenZFS and Btrfs, everyone was just guessing
#62I 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…
A lot of end users run ZFS through TrueNAS/FreeNAS and I indeed found that community to spread a lot of misinfo and un-actionable advice. I liken them to gamers lapping up any snake oil solution to get 0.1 fps more. I would suggest anyone trying to learn about ZFS to avoid it, it definitely was counter-productive to me. Reddit, random blogs and official documentation (often that by Oracle) turned out to be much bette…
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?
Re: In OpenZFS and Btrfs, everyone was just guessing
#63Earlier quoted context omitted.
Network drivers contribute to "bugs" surprisingly often. I've had my share of issues with them. I'd go as far to claim this: If you're shipping a product that relies on networking at your customer's premises you basically need to maintain a list of cards and drivers that you support. Especially if you're doing anything weird, where "weird" means anything but bog standard TCP.
How can network driver corrupt a database?
Most network drivers run in kernel context and can access and write to everything.
Additionally, unless your system has an iommu and configures it to strictly limit your NIC, most NICs can DMA to any address in memory.
Unintentionally providing the wrong address to receive a packet with is a great way to corrupt a database.
Re: In OpenZFS and Btrfs, everyone was just guessing
#64Earlier quoted context omitted.
I like it! Seems like a great way to incentivise companies to contribute.
> I like it! Seems like a great way to incentivise companies to contribute. It also helps with lawsuits, which was a major thing right at the beginning of history of BSD. * https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.... . Linux later had the lawsuit issue with SCO and IBM and tracking where certain things came from (which was not helped by the fact that Linus Torvalds refused to use source code track…
The beginning of BSD was the 1978 shipment of 1BSD by Bill Joy.
You likely mean the end of the effort to replace all AT&T code, which was more than a decade later.
Re: In OpenZFS and Btrfs, everyone was just guessing
#65First, there is a FreeBSD Errata Notice for this that offers an nice quick collection of the various bugs and subsequent repairs, with links to summaries, for anyone who is catching up on this issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275308 Second, I don't like the editorialization of this title ("In OpenZFS and Btrfs, everyone was just guessing") at all. No, nobody was "just guessing", but as far as…
Yep, this is how I ended up running ZFS. Because with XFS the answer to "oh no a power cut" was "lol, a bunch of files might be zeros. Figure out which ones." The whole weird implication that there's something else which is perfect is always bizarre: there isn't, everyone knows that, it's extremely non-trivial to do that.
Wasn't this XFS problem solved by write barriers?
I remember that happening to me once long ago, but never on rhel 7 or above.
Re: In OpenZFS and Btrfs, everyone was just guessing
#66Earlier quoted context omitted.
The hardest bug I have ever worked with was an embedded device losing all data on the flash chip. But the issue was, this was happening even after we removed all instructions to delete data from the flash. The device had most traces between controller and flash completely hidden as a precaution for hacking/snooping, making it extremely difficult to diagnose the issue as the issue completely vanished in a test harness…
Another source of bogus commands can be brownouts. When the voltage is low enough to confuse communication signals, but not low enough to prevent destructive events from occurring.
>> 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 speeds slowed. The first circuit to fail was something in the branch condition logic. This caused all conditionals to not branch, which lead to running all code in the memory space in order. That included a few instructions to.... fire the airbag. It was a rare thing, but a very big deal.
Re: In OpenZFS and Btrfs, everyone was just guessing
#67Earlier quoted context omitted.
A lot of end users run ZFS through TrueNAS/FreeNAS and I indeed found that community to spread a lot of misinfo and un-actionable advice. I liken them to gamers lapping up any snake oil solution to get 0.1 fps more. I would suggest anyone trying to learn about ZFS to avoid it, it definitely was counter-productive to me. Reddit, random blogs and official documentation (often that by Oracle) turned out to be much bette…
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 comment.
Re: In OpenZFS and Btrfs, everyone was just guessing
#68Earlier quoted context omitted.
ZFS will still be preferable for production for a long while until bcachefs has proven itself, and bug reports slow down. That said, I'm also stoked for bcachefs. ZFS has always appeared to me like a bloated mess. Btrfs is more minimal, but too much so, in that it doesn't do parity (at least very reliably), which sucks because I don't always want mirroring. And it has a reputation for gobbling your data up. If bcache…
What does bcachefs need that it doesn't have?
Going by the most recent Phoronix benchmarks it still needs a fair bit of optimization work. Of course, I'm glad that Kent is focusing on squashing bugs and polishing the architecture first.
Re: In OpenZFS and Btrfs, everyone was just guessing
#69Earlier quoted context omitted.
You're at odds with the desire (necessity, actually) to have precise low-level control, not just of the in-memory layout of the data structures, but also of the performance characteristics of your code (e.g. no unnecessary pointer-chasing). Higher-level languages tend to make it easier to pile up abstractions; we want the orthogonal property of making it harder to shoot yourself in the foot. You can look at ZFS for i…
I like Rust, but you are going to be writing a lot of unsafe Rust for a filesystem implementation. Multiple processes are writing to the filesystem simultaneously. "Ownership" is fuzzy and is moving around. At that point, is Rust buying you anything for how much it's going to get in your way? I really don't see an advantage to Rust when operating at these kinds of low levels.
There are entire kernels written in Rust with 10% or less unsafe code.
Re: In OpenZFS and Btrfs, everyone was just guessing
#70OpenZFS 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…
I’m sure for those who encountered it, it’s not easy to dismiss. But it does seem like this might be getting a little extra attention perhaps because it’s relatively uncommon to hear about a flaw in ZFS at all.
Drawbacks and tradeoffs abound, but outright “bugs” doesn’t seem like something ZFS is generally associated with.