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

61–70 of 110 posts

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

#61

Post by koverstreet »

kev009 wrote: post #35
jdc wrote: post #28

Earlier quoted context omitted.

I lost data on my workstation running brtfs in 2016, but would give it another shot if I knew I could expect reliability from it. Makes me wonder if anyone's tried something like Jepsen for filesystems.

https://github.com/kdave/xfstests is the old standard. Folks have also been using AFL to fuzz. In ZFS, zdb is often used for similar purposes.

xfstests is still the standard, on Linux - https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git

I use it pretty much every day.

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

#62

Post by j3097736 »

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…

I purposefully ran btrfs on a malfunctioning drive for over a year (kernel 3.12, only metadata dup), much more reliable than ext4 which would lock up the entire filesystem on read/write failure and often go read-only, with btrfs the only visible signs of malfunction were dmesg and the scrub log.

Also been using it as / since 2012 with no issues.

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

#63

Post by kazinator »

barrkel wrote: post #52
kazinator wrote: post #39

Earlier quoted context omitted.

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.

Well, there are other reasons; you want to write code that operates on the data, and neither the code nor the data fits on a single machine - you have to target an abstraction which spans machines. Block storage is too low-level an abstraction. That isn't to say that using high performance block storage isn't still a win even when the redundancy is multiplied at a higher level. The higher level redundancy is also abo…

Block storage can be network-abstracted.

Even virtual memory for that matter. Now ancient concept:

https://en.wikipedia.org/wiki/Distributed_shared_memory

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

#64

Post by binarycrusader »

Mister_Snuggles wrote: post #17
std_throwaway wrote: post #13

Earlier quoted context omitted.

At first glance, the status page of btrfs look horrible: https://btrfs.wiki.kernel.org/index.php/Status The problem areas are mostly RAID and exotic features. RAID can be handled by a different layer and most users don't really need the exotic features. Judging from the media silence in the last months I'd say either people stopped using btrfs or it just about works good enough for everbody.

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.

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

#65

Post by syshum »

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…

btrfs ran before it could walk.

It is ok for a single disk FS. It is no ZFS though which is its largest problem, people keep marketing it as "linux awnser to ZFS"

No, it is not.

Maybe some day, but today it is no ZFS. I love zfs..

Further the ZFS utilities are far easier to use and understand. zfs and zpool commands well documented, and intuitive. btrfs utilities are are not, IMO

I am fine with using btrfs as a replacment for ext on my OS drive, but for my large data arrays of multiple disks it s ZoL all the way

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

#66

Post by jethro_tell »

rsync wrote: post #24
jethro_tell wrote: post #3

I like that we are seeing competition in this space. I think it's good for business. I do however see some big red flags in the linked page: > Starting from there, bcachefs development has prioritized incremental development, and keeping things stable, and aggressively fixing design issues as they are found Which is it? Big design changes or stable FS?

"I like that we are seeing competition in this space. I think it's good for business." I wonder why Hans Reiser doesn't take up filesystem work again ? He has plenty of time on his hands ...

You know honestly, I've always wondered why prisons don't have a bunch of computers for retaining. I mean, if there's a chance of conspiracy a specific inmate shouldn't have access, but your run of the mill street thug would probably really benefit from learning Linux system administration, web site building, coding . . .. It would probably be a lot easier to find gainful employment in a high demand field and would help break the cycle. If they were allowed to work, the people with longer sentences could help break the cycle for their dependants as well.

Guess that's probably the answer.

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

#67

Post by throw2016 »

Chris Mason and the btrfs team are clearly talented. But the initial excitement of btrfs has sadly dissipated and its promise as the next generation Linux fs remains unrealised. It now feels a bit jaded and the momentum is spent.

I suspect many have lost patience with the promise of COW and unfortunately for bcachefs this history will cast a shadow on its development and potential.

Database performance remains problematic on COW and while things like snapshots and adhoc disk and volume management are interesting even exciting one soon realises unless one has a pressing need they are just nice to have. Eventually boring ext4 ticks all the boxes and one may as well forget about the fs and focus elsewhere.

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

#68

Post by indolering »

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

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

#69

Post by aarmenaa »

kzrdude wrote: post #30
_ecqc wrote: post #25

Earlier quoted context omitted.

Are you running BTRFS with its built in RAID? That's been the biggest blocker for me. There have been numerous RAID bugs that have caused data-loss and I believe at least one of them is still unpatched.

I think Chris Mason is open with that raid support is not really stable yet, right? Status page says so: https://btrfs.wiki.kernel.org/index.php/Status

As far as I know they consider RAID0, 1, and 10 to be stable. Last time I used it rebuilds were substantially slower than ZFS or mdraid. Rebuild performance seems to one of a few issues that BTRFS has had trouble solving. RAID 5 and 6 were declared stable last year, only to have that retracted when some fatal flaw was discovered that would apparently cause data loss if you needed to rebuild.

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

#70

Post by __david__ »

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.
Post reply on HN