Live data from Hacker News

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

bcachefs.org

41–50 of 110 posts

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

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

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

This might be the case if you're running something incredibly easy on I/O like large sequential read/writes, but if you do anything at all challenging on I/O like opening desktop applications (Photoshop, lots of random reads), editing or viewing high bitrate video (very high throughput) or god forbid running a database, this is a huge problem.

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

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

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

#43
post #16

I think ZFS is the only viable open source CoW total storage management option commercially. These new Linux filesystems are way too late to the party, and it will take a decade for them to reach maturity when they reach basic 1.0 feature parity. In parallel I see XFS as the long term evolution for Linux file systems. It will continue to scale slightly up from where it sits today and address fail in place, flash, met…

I think ZFS is fantastic for businesses but there are a couple places where it falls short compared to bcachefs for me:

- For non-business users who want a RAID, ZFS is too inflexible. You can't add or remove disks to a RAIDZ vdev. If you want the space efficiency of RAIDZ, you have to expand your array in units of entire vdevs. If you want replicas, you have to expand in at least pairs of disks. BTRFS and bcachefs both allow you to replicate more flexibly and reshape your array.

- ZFS doesn't work particularly well with SSDs as caches. ZIL and L2ARC are nice but they're not as nice as a full bcache-style tiering setup. bcachefs tiers let you do crazy things like a 4-tier storage setup with Nearline HDD -> 15k SAS HDD -> SATA SSD -> NVMe SSD.

- ZFS is pretty complex to manage in general and major features like ZIL and L2ARC are arcanely documented. So far, bcachefs is pretty straightforward to use.

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

#44
post #16

I think ZFS is the only viable open source CoW total storage management option commercially. These new Linux filesystems are way too late to the party, and it will take a decade for them to reach maturity when they reach basic 1.0 feature parity. In parallel I see XFS as the long term evolution for Linux file systems. It will continue to scale slightly up from where it sits today and address fail in place, flash, met…

[deleted]

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

#45

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.

I'm a big opensuse fan, but none of my opensuse machines are running btrfs.. Although, besides the stability (which can't really be much worse than ext4/xfs which is what I apparently choose on the two machines) I think what drove me nuts about opensuse's use of btrfs was all the subvolumes. Which are cool, but just another thing for me to deal with, and my computing theory for the past few years can be summarized by "KISS, unless its really hurting".

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

#46
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 b…

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

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

#47
post #40
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.

I'm using BTRFS on many VMs running Ubuntu servers, and I find that expanding the virtual hard-disk, on Proxmox, without stooping the VM it's far trivial.

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

#49
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…

Likewise, I've run it on hundreds of machines over the past three years without issue. I do continue to use EXT4 for database hosts as it far outperforms BTRFS with PostgreSQL from what I've seen.

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

#50
post #5

While I really like these sort of file systems, I'm not holding my breath. This isn't a simple filesystem project, but plays in the next-gen space ZFS opened up. There will be a lot to do, especially IO scheduling, RAID safety with shitty drive firmwares, consistency guarantees with fsync/partial flushes etc. I'm pessimistic about it being mainlined in the near future, the core team will be weary of a second btrfs. W…

Well we can still hope that Apple might open source APFS (and add data checksums).

Or that someone sits down and does the reverse engineering work.

Post reply on HN