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

31–40 of 110 posts

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

#31

Post by rrauenza »

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'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 btrfs balance along with a mount -oremount,clear_cache. I also run the latest kernels from http://elrepo.org instead of the CentOS7 kernels so that I get the latest patches.

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

#32

Post by corppneq »

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

from site:

> Bcachefs is not yet upstream - you'll have to build a kernel to use it.

> Snapshot implementation has been started, but snapshots are by far the most complex of the remaining features to implement -

Yes. Very mature.

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

#33

Post by sedachv »

mschuster91 wrote: post #29
sedachv wrote: post #27

Earlier quoted context omitted.

> What I would like to see is a APFS/exFAT crossover with COW and data checksums without all the volume mgmt with ports for all possible operating systems so everyone can use it for their SDcards, usb-sticks and external drives without making tradeoffs and using fuse. +1. Filesystems without bit-rot protection on flash drives are going to become at least as big a problem as optical disc rot.

> without making tradeoffs and using fuse. What's the problem with fuse? It allows sharing code between Linux, OS X, (Free)BSD and even Windows (via dokan). Yes, it will not offer you the same performance as an in-kernel driver (due to context switches), but given that CPU power always increases, no big problem there.

> What's the problem with fuse?

1. Only available on Android when rooted.

2. Support varies between OSes. For example OpenBSD's FUSE does not have the default_permissions/allow_other flags, which makes for example encfs (and any other virtual filesystems that are backed by multiple files) a pain to use since OpenBSD 6.0 removed user mounting.

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

#34

Post by user5994461 »

std_throwaway wrote: post #13
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).

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.

> 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.

3rd option: there aren't really much people who ever used btrfs.

from the feedback I could gather when I enquired about it, it's 33/33/33:

33% who tried and say it's fine

33% who tried, hit a few bugs and stopped

33% who say it's known for not really being finished, not a good idea to go for it.

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

#35

Post by kev009 »

jdc wrote: post #28
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 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.

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

#36

Post by khc »

sedachv wrote: post #33
mschuster91 wrote: post #29

Earlier quoted context omitted.

> without making tradeoffs and using fuse. What's the problem with fuse? It allows sharing code between Linux, OS X, (Free)BSD and even Windows (via dokan). Yes, it will not offer you the same performance as an in-kernel driver (due to context switches), but given that CPU power always increases, no big problem there.

> What's the problem with fuse? 1. Only available on Android when rooted. 2. Support varies between OSes. For example OpenBSD's FUSE does not have the default_permissions / allow_other flags, which makes for example encfs (and any other virtual filesystems that are backed by multiple files) a pain to use since OpenBSD 6.0 removed user mounting.

1. most filesystems won't be available on Android anyway, this point is moot

2. most non-fuse filesystems won't be ported to your BSD of choice anyway

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

#38

Post by koverstreet »

aseipp wrote: post #26
rsync wrote: post #22

Earlier quoted context omitted.

"but snapshots are by far the most complex of the remaining features to implement" I thought defrag (or things like defrag) was the most complicated thing to implement ? ZFS has always had snapshots but I am told defrag is a long, long ways away ...

According to Kent on Reddit, bcachefs technically had online defrag since it was just bcache -- via the copying garbage collector for reclaiming space. So bcachefs will simply inherit that feature by design, which is great. Apparently copygc is off right now because reasons, though (I'm going to assume it's almost certainly the related extent/compression issue that's holding this up from being enabled, which you can…

I should have been more clear - copygc is off by default in upstream bcache, it's on in bcachefs (and required, in order to guarantee a capacity when doing random writes)

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

#39

Post by kazinator »

feld wrote: post #15
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.

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.

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

#40

Post by noja »

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…

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