Live data from Hacker News

Bcachefs: “the COW filesystem for Linux that won't eat your data”

bcachefs.org

91–100 of 110 posts

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#91
post #60

Earlier quoted context omitted.

ZFS is not GPL? I dunno, I like feeling safe when I do kernel upgrades knowing even if for whatever reason my ZFS module doesn't compile/work under the new kernel, I won't be left without a root FS. I have been running BTRFS for 5 years with very little issues, and enjoy not having to compile a new dkms module with every kernel.

ZFS with DKMS is a disaster, at least in my experience. Honestly, I can't recommend ZoL unless you're running a distro with relatively stable kernel releases that don't change substantially or that happens to be supported by ZoL with binary packages. ZoL on Arch was... trying at times. It worked great, but my paranoia meant that I ended up adding the kernel to IgnorePkg to force manual kernel updates (mostly for my o…

> ZFS with DKMS is a disaster

It is more like Arch Linux is a disaster. Upgrading the kernel package replaces the current one! Come on, any distribution worth it's salt just installs new versions alongside and you can select any of them in the boot screen. This is a ridiculous packaging policy regardless of ZFS or any other DKMS modules.

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#92

Earlier quoted context omitted.

ZFS with DKMS is a disaster, at least in my experience. Honestly, I can't recommend ZoL unless you're running a distro with relatively stable kernel releases that don't change substantially or that happens to be supported by ZoL with binary packages. ZoL on Arch was... trying at times. It worked great, but my paranoia meant that I ended up adding the kernel to IgnorePkg to force manual kernel updates (mostly for my o…

> ZFS with DKMS is a disaster It is more like Arch Linux is a disaster. Upgrading the kernel package replaces the current one! Come on, any distribution worth it's salt just installs new versions alongside and you can select any of them in the boot screen. This is a ridiculous packaging policy regardless of ZFS or any other DKMS modules.

And I acknowledged that using it on a different distro would be more advisable, although I still stand by my claim that FreeBSD is far more appropriate for ZFS.

I will, however, agree that having no fallback to the prior kernel version is a problem. In practice, it's never caused me much trouble except when I do something stupid like using ZFS from the AUR. initrd generation has historically seemed to be more problematic under Arch, but I'd argue that's mostly fixed with install hooks.

In all honesty, it was probably more the fault of the zfs-dkms packages than it was either the kernel packaging policy or ZoL+DKMS itself (for reasons I elaborated on in my original post).

But, that's also what you get when you use packages from the AUR or using a distro like Arch for something that really only benefits from a wider installation base (like Ubuntu does, for instance).

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#93
post #82

Earlier quoted context omitted.

ZFS with DKMS is a disaster, at least in my experience. Honestly, I can't recommend ZoL unless you're running a distro with relatively stable kernel releases that don't change substantially or that happens to be supported by ZoL with binary packages. ZoL on Arch was... trying at times. It worked great, but my paranoia meant that I ended up adding the kernel to IgnorePkg to force manual kernel updates (mostly for my o…

I have been running ZFS on Arch Linux for a little over two years across four drives, and doing weekly updates. Haven't ran into any issues yet.

I'm actually surprised by this, but I'd wager that you also didn't use the DKMS AUR packages. I also suspect you wait for the zfs-linux (etc) packages to match the kernel version before updating. Or you manually bump the kernel version and build it, hoping for the best (edgy!).

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#94
post #87

Earlier quoted context omitted.

ZFS with DKMS is a disaster, at least in my experience. Honestly, I can't recommend ZoL unless you're running a distro with relatively stable kernel releases that don't change substantially or that happens to be supported by ZoL with binary packages. ZoL on Arch was... trying at times. It worked great, but my paranoia meant that I ended up adding the kernel to IgnorePkg to force manual kernel updates (mostly for my o…

Arch Linux has a LTS kernel available in official repo. Why not using that?

I considered it, but I have some problems with the Arch LTS release cycle. If I were to choose an LTS kernel, why not just dump Arch and go with an Ubuntu LTS, which has better long term support?

The other problem is that at the time, the ZFS packages for LTS were pinned at a version that had a known issue with arc_reclaim encountering a deadlock essentially causing the file system to become unresponsive after a substantial transfer (think rsync).

Now, obviously, it wouldn't be that difficult to modify the PKGBUILD to pull a newer version of ZFS, but there's a point in time where the maintenance required to update starts to outweigh whatever benefit you can glean from the LTS kernel.

That's not the case now since the LTS packages appear to be at v0.6.5.9, which has the fixes, but I don't remember this being true about a year ago.

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#95

Earlier quoted context omitted.

ZFS with DKMS is a disaster, at least in my experience. Honestly, I can't recommend ZoL unless you're running a distro with relatively stable kernel releases that don't change substantially or that happens to be supported by ZoL with binary packages. ZoL on Arch was... trying at times. It worked great, but my paranoia meant that I ended up adding the kernel to IgnorePkg to force manual kernel updates (mostly for my o…

Your problem was running it on a distro the didn't support it. (As you acknowledge.) So far it's been running absolutely great for me on several Ubuntu installs.

Indeed. Arch is good for a few things, but sometimes stability isn't one of them when it comes to unsupported packages. ;)

I'm not sure I'd be brave enough to run ZoL again, but given Ubuntu's FAR wider install base and availability of binary packages, it's the better option if you have to choose.

My personal preference would be to stick with ZFS on FreeBSD. Performance is probably better.

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#96

Earlier quoted context omitted.

OpenSuSE uses btrfs by default and relies on it for one of it's killer features. Before a system change, such as installing updates, changing services configuration, etc, is made using YaST, snapper takes a snapshot of the root filesystem. If something breaks, just roll back to the previous working state. I'd say that for the OpenSuSE folks, btrfs falls squarely into the "good enough" category.

FWIW, Solaris has been providing similar upgrade safety via ZFS since 2008.

Sadly, I got out of the Solaris game a couple of years before ZFS became a thing. I'm using ZFS on FreeBSD though, I quite like it.

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#97

Earlier quoted context omitted.

His Patreon page[1] shows he only receives $762 in donations a month, less than a third of what he needs to keep from eating into his personal savings. Sad given how much a modern filesystem would help Linux : ( [1]: https://www.patreon.com/bcachefs

> As far as I know, they're still actively violating the GPL Maybe he can get extra money from a lawsuit?

Few people would willingly sign up for that kind of torture.

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#98

Earlier quoted context omitted.

OpenSuSE uses btrfs by default and relies on it for one of it's killer features. Before a system change, such as installing updates, changing services configuration, etc, is made using YaST, snapper takes a snapshot of the root filesystem. If something breaks, just roll back to the previous working state. I'd say that for the OpenSuSE folks, btrfs falls squarely into the "good enough" category.

FWIW, Solaris has been providing similar upgrade safety via ZFS since 2008.

Yes, operating systems other than OpenSUSE have this feature. TrueOS (formerly PC-BSD) has had it for some years, too.

* https://blog.pcbsd.org/2012/07/9-1-feature-multiple-boot-env...

* https://blog.pcbsd.org/2013/06/pc-bsd-status-update/

* https://www.ixsystems.com/blog/a-closer-look-at-the-changes-...

* https://www.ixsystems.com/blog/the-revamped-life-preserver/

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#99
post #12

It looks like it takes quite some time till it is fully implemented. Why should we start using it right now instead of btrfs/zfs?

You probably shouldn't. It's ready for adventurous testers, and is pretty stable, but unless you're willing to report bugs or hack on it, you can probably stay away. There are reasons to still want it, despite its newness; for example, the latest updates bring huge improvements in metadata efficiency (low metadata overhead -> more metadata in the cache -> larger working set). Someone on the IRC channel reported it's…

Do you have any similar thoughts about HAMMER (from DragonFly BSD)?

Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”

#100
post #81
post #40

Earlier quoted context omitted.

Me too. I love it, but only with raid-1 or no raid. btrfs as a filesystem will be dead within the next 12 months unless they fix raid-5 and raid-6.

I think RAID 5/6 will be dead before btrfs.

How are you doing redundancy then? Raid-1?
Post reply on HN