Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In OpenZFS and Btrfs, everyone was just guessing

phoronix.com

Post reply on HN
Print view View original

31–40 of 172 posts

Re: In OpenZFS and Btrfs, everyone was just guessing

#31

Post by mcpackieh »

seanw444 wrote: post #24
mcpackieh wrote: post #12

I have been more than satisfied with single-drive Btrfs with OpenSUSE so far, but nevertheless I can't wait for bcachefs to prove itself. On paper at least, bcachefs seems like the most attractive of the three.

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…

bcachefs's caching (foreground_target, promote_target, background_target) seems more straight forward than ZFS's ZIL/L2ARC stuff since with bcachefs you can use the same device for accelerating writes and reads of frequently accessed files, while (from what I understand) with ZFS you need two partitions, one for each. I'm not a ZFS expert by any means so maybe I've got the wrong ideas, but bcachefs seems a lot more elegant and straight forward in many regards. Still, I'm not jumping to adopt a brand new filesystem.

Re: In OpenZFS and Btrfs, everyone was just guessing

#32

Post by hotpotamus »

donmcronald wrote: post #18

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…

One of my favorite comments chains here was was something to the affect of:

Commenter posts a nice summary of how ZFS will try a quick compression algorithm to see if a block is even compressible and then try other more expensive ones to achieve better compression.

Another commenter asks how they know that.

First commenter replies that they wrote the code for it.

Nothing more than a ZFS user (to some extent my company relies on it even) here, so I just try and color inside the lines, but I'm ever impressed by it.

Re: In OpenZFS and Btrfs, everyone was just guessing

#33

Post by endigma »

seanw444 wrote: post #24
mcpackieh wrote: post #12

I have been more than satisfied with single-drive Btrfs with OpenSUSE so far, but nevertheless I can't wait for bcachefs to prove itself. On paper at least, bcachefs seems like the most attractive of the three.

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?

Re: In OpenZFS and Btrfs, everyone was just guessing

#34

Post by seanw444 »

endigma wrote: post #33
seanw444 wrote: post #24

Earlier 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?

I worded it weirdly. It has what it needs already I think, but I'm saying: if it can reliably and efficiently do all the most useful functions of ZFS, while being built-in to Linux, and not starting off terribly bloated, that will be fantastic.

Re: In OpenZFS and Btrfs, everyone was just guessing

#35

Post by emaste »

solarkraft wrote: post #27
lvncelot wrote: post #7

Earlier quoted context omitted.

Sidenote: What a great commit message. The expanded comment explains why both checks are necessary, but the commit message gives so much more context for anyone wondering and `git blame`ing that line.

Totally. Also: I've never seen Sponsored-by: > Signed-off-by: Rob Norris > Sponsored-by: Klara, Inc. > Sponsored-by: Wasabi Technology, Inc.

This is a longstanding tradition from FreeBSD. A list of our commit message trailers: https://docs.freebsd.org/en/articles/committers-guide/#_incl....

"Sponsored by:" search in FreeBSD commit messages: https://freshbsd.org/?q=%22Sponsored+by%3A%22

Re: In OpenZFS and Btrfs, everyone was just guessing

#36

Post by emaste »

dmpk2k wrote: post #16

While I am firmly in the ZFS camp, my feeling is that there has indeed been a gradual slide in the disciplined development of ZFS. After some initial bumps in brand new software, the Sun kernel group did a good job of avoiding corruption. Once Sun was absorbed by Oracle, OSS ZFS moved into illumos, who were overall quite good at doing the same (although they had less resources to play with). OpenZFS brought ZFS to th…

Note that the bug that is the topic of discussion here predates OpenZFS. Whether or not there has been a slide in disciplined development in OpenZFS, this bug does not support that assertion.

Re: In OpenZFS and Btrfs, everyone was just guessing

#37

Post by RantyDave »

donmcronald wrote: post #18

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…

On the other hand there are a couple of things in ZFS that can make a big difference. For instance: changing the page size to be the same size as Postgresql uses (8kb); disabling the writing of 'last accessed' timestamps; or whether or not the filesystem attempts deduplication. From what I remember (it's been a while) these can be configured on a per-dataset basis, where a dataset is a lightweight filesystem more akin to a directory, and many of them can be changed on a live filesystem.

Here, have at it: https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops...

So personally I'd encourage messing around (on something non-prod, of course). Measure measure measure! Does it actually make any difference.

It's a shame a bug crept in to an otherwise pretty much faultless filesystem. I'm sure there are some truths in there about commercial support or not running the bleeding edge or whatever. And making backups, even for ZFS backed filesystems. Sacrilege, I know.

Re: In OpenZFS and Btrfs, everyone was just guessing

#38

Post by mghardal »

onetimeuse92304 wrote: post #25
nabla9 wrote: post #3

> Everyone, literally, is just guessing. And then running scripts to evaluate the odds that things are actually working correctly. Just like BTRFS. When filesystem or databases have serious bugs, they are often heisenbugs. Incredibly hard to pin down. You need to be able to replicate the bug to find what is happening. In one of the first jobs I had, large Oracle database started to corrupt data repeatedly about once…

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…

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.

Re: In OpenZFS and Btrfs, everyone was just guessing

#39

Post by favorited »

solarkraft wrote: post #29
donmcronald wrote: post #18

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…

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…

I think it comes down to the fact that the TrueNAS developers treat it as an appliance (which is a good thing, IMO). However, because so many people's only experience with ZFS is TrueNAS, when iXsystems says "Doing X on TrueNAS is a bad idea, that's not a configuration we support," it gets cargo culted as "doing X on ZFS is bad."
Post reply on HN