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

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

bcachefs.org

Post reply on HN
Print view View original

101–110 of 110 posts

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

#101

Post by rrauenza »

gigatexal wrote: post #56
rrauenza wrote: post #31

Earlier quoted context omitted.

I've been using btrfs since about 2014 on CentOS7. I only use it with mirroring+compression. No snapshots. I mostly went with it for data scrubbing and compression. My experience has been mixed, but haven't had any data loss. There was a bug for a while regarding free space so occasionally the system would seem to be full but wasn't ....and it was a real pain to correct it. I now have a cron job that does a monthly b…

ZFS gets you all of that and raid and snapshots and has been tested time and time again. Why run BRTFS then?

At the time of the system build, ZFS was user space only on CentOS7 if I recall.

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

#102

Post by rrauenza »

Zardoz84 wrote: post #46
rrauenza wrote: post #31

Earlier quoted context omitted.

I've been using btrfs since about 2014 on CentOS7. I only use it with mirroring+compression. No snapshots. I mostly went with it for data scrubbing and compression. My experience has been mixed, but haven't had any data loss. There was a bug for a while regarding free space so occasionally the system would seem to be full but wasn't ....and it was a real pain to correct it. I now have a cron job that does a monthly b…

Why the remount,clear_cache ? I'm doing a monthly balance before I got problems on a few servers.

It's a little black magic -- didn't have time to completely research (this is a home NAS system.)

I believe there was a bug in the clear space cache. This could cause the system to think it didn't have free blocks... you'd have to mount another device to create more space in order to rebalance and fix.

Eventually I saw a bug fix report about a corruption in the cache... I never investigated to see if my current kernel has the fix.

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

#103

Post by kzrdude »

indolering wrote: post #68
slavapestov wrote: post #58

Here's a funny story. At one point bcache development was funded by a startup (which I won't name here). They were using it as the local storage layer of a distributed storage product. I worked there for a year in 2014. Apparently they were not aware of the fact that bcache was a) GPLd code, or b) developed before the company existed, first as a hobby project and then at Google. After a couple of years, they noticed…

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

Sad, but it's absurd either way that 1 person should write the next file system. A team is needed.

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

#104

Post by fulafel »

kazinator wrote: post #39
feld wrote: post #15

Earlier quoted context omitted.

when the RAID is handled by a different layer you lose some very important integrity features

That's why all big data in big corporations uses exotic-open-source-filesystem-based RAID. That's where the action is when it comes to integrity. None of that virtual block device or driver-level software junk, let alone hardware RAID controller solutions.

I think the high profile ones (Google, Amazon etc) use relatively dumb OS drivers and do the fancy distributed FS abstraction stuff in userspace. Certainly stuff like Ceph and Gluster don't have very good reputations and are mostly sold to relatively clueless "enterprise" customers.

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

#105

Post by untoreh »

__david__ wrote: post #70
zanny wrote: post #21

I've been using btrfs since about 2011, and I've stopped using ext4 / xfs / zfs everwhere since about 2014. From 2012-2014 it was mostly breakage every other month. From 2014-2016, it was semi-annual issues. For the last ~18 months I have had ~30 machines running btrfs with no issues, some servers, some personal computers. The release notes are boring, the bugs are boring, and to me its definitely in a state I would…

How is the speed now? I never had data issues but I definitely had speed issues. Btrfs was really slow compared to ext4/xfs back when I tried it. And I mean orders of magnitude slow. I had an application that did a lot disk access and switching off of btrfs brought the runtime down from a week to just hours. I want to like btrfs, but after that I just can't trust it for high disk load situations.

with cow is still slower than zfs. It still uses lzo for compression whereas zfs uses lz4, which is 10x faster for decompression.

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

#106

Post by untoreh »

Veratyr wrote: post #42
boris wrote: post #2

>Snapshot implementation has been started, but snapshots are by far the most complex of the remaining features to implement Snapshots are the #1 feature of COW filesystems. I've been using them for a bit in btrfs and this feature is game-changing (and no, it hasn't eaten my data yet).

This is kinda a subjective thing though. For me the #1 feature is being resilient to bitrot.

if you disable cow, you also disable checksumming, so they are kinda linked

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

#107

Post by kasabali »

Zancarius wrote: post #92
kasabali wrote: post #91

Earlier quoted context omitted.

> 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 problem…

I know you acknowledged that using it on a different distro would be more advisable, I just wanted to vent about more broad issue of their packaging policy. Sorry if it wasn't clear.

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

#108

Post by binarycrusader »

Mister_Snuggles wrote: post #96
binarycrusader wrote: post #64

Earlier quoted context omitted.

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.

Yes, FreeBSD adopted the same command Solaris has for boot environment management -- see the beadm man page.

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

#110

Post by Zancarius »

kasabali wrote: post #107
Zancarius wrote: post #92

Earlier quoted context omitted.

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 problem…

I know you acknowledged that using it on a different distro would be more advisable, I just wanted to vent about more broad issue of their packaging policy. Sorry if it wasn't clear.

Oh, I understood where you're coming from.

I do agree. There are circumstances where Arch's packaging is brain dead (they only recently, within the last 2 years or so, started validating packages against signatures!). I use it for a number of applications, and as my desktop OS among others. However, I'll freely admit at least part of my choice is perhaps the fault of masochistic tendencies. After all, I migrated to Arch from Gentoo, and I used Gentoo for years! :)

In all honesty, I've been bit more by the initrd and mkinitcpio's failings than the lack of a fallback kernel. That's mostly fixed with packaging hooks that essentially guarantee it will run, but it's still a problem with the ZFS packages and may require running it manually (which is annoying). However, that wasn't always the case, and sometimes the generated initrd would be missing something important. You can imagine what happened next.

Post reply on HN