SUSE reaffirms support for Btrfs

Posted Aug 24, 2017 16:16 UTC (Thu) by drag (guest, #31333)
In reply to: SUSE reaffirms support for Btrfs by SEJeff
Parent article: SUSE reaffirms support for Btrfs

Anybody interested in Kent Overstreet and Bcachefs project should help support him financially. https://www.patreon.com/bcachefs Or maybe just hire him to work on it. :)

I don't have any experience with his previous project, bcache, but it seems to have been successful.

SUSE reaffirms support for Btrfs

Posted Aug 24, 2017 22:52 UTC (Thu) by vstinner (subscriber, #42675) [Link] (5 responses)

BcacheFS seems to be a clone of btrfs with a single developer and the project is very young. Btrfs has many dev, is used in production since many years (ex: used by Facebook, no?) and is part of the Linux kernel. How is BcacheFS better or more hype? BcacheFS seems to have performance issues, at least mount time, which can be a blocker issue on very large volumes.

I am a happy user of btrfs. I like snapshots to recover files if I make a mistake l already lost and recovered from a snapshot photos of a travel to Japan). I recently enabled raid1 (plug a second disk) with 400 GB of data. It's done in two trivial commands in 2 hours (likely maximum write speed of my HDD). I love data checksum to check if my photos are still there! I never lost any file. I never had any major issue with btrfs in 3 years. No idea why some people speak about data loss? It's common that I turn off this server by holding the power button 4 seconds :-) btrfs has a fsck tool, no? (I didn't check since I had never any issue.)

SUSE reaffirms support for Btrfs

Posted Aug 28, 2017 9:45 UTC (Mon) by anton (subscriber, #25547) [Link]

A properly done journaling or COW file system does not need an fsck to recover from a power outage or kernel crash. The value of an fsck in other circumstances is also dubious; nevertheless, there is "btrfs check", although there are other options you should try first.

SUSE reaffirms support for Btrfs

Posted Aug 29, 2017 3:59 UTC (Tue) by thoughtpolice (subscriber, #87455) [Link] (3 responses)

bcachefs is spun out of bcache, which has already been part of Linux for several years as well. It's more an evolution of bcache's design rather than something from scratch, so it's already proven to be pretty stable.

Also, bcachefs is as much a clone of btrfs as btrfs is of ZFS -- they're all "next-gen" filesystems, but naturally they all have different points in the design space. For example, it features very efficient metadata overhead, in some cases leaving to order-of-magnitude improvements over others (because metadata can effectively fit in your L2 cache -- a user on IRC once reported bcachefs vs <anything else> was something like 500,000 files/s vs < 70,000 files/s, in a directory with a few hundred thousand files.) bcachefs also has very good tail latency compared to most systems because it doesn't block necessarily.[1]

Finally, one of the biggest features is bcachefs is it is portable by design. It already builds in userspace on Linux (the same code that is built into the kernel module) and Kent is working on FUSE bindings. It seems likely at some point bcachefs will likely end up on other operating systems quite easily (even Windows or OS X.) This feature also dovetails nicely with e.g. out-of-the-box encryption (no dm-crypt), meaning any system will have native encryption support.

I'm much more excited for bcachefs than I was for btrfs, if it can fix some of its flaws like the above.

[1] https://www.patreon.com/posts/performance-in-7395461

SUSE reaffirms support for Btrfs

Posted Aug 29, 2017 5:40 UTC (Tue) by kreijack (guest, #43513) [Link] (2 responses)

> Also, bcachefs is as much a clone of btrfs as btrfs is of ZFS -- they're all "next-gen" filesystems, but naturally they all have different
> points in the design space. For example, it features very efficient metadata overhead, in some cases leaving to order-of-magnitude
> improvements over others (because metadata can effectively fit in your L2 cache -- a user on IRC once reported bcachefs vs
> <anything else> was something like 500,000 files/s vs < 70,000 files/s, in a directory with a few hundred thousand files.) bcachefs also
> has very good tail latency compared to most systems because it doesn't block necessarily.[1]

Due to the fact that the snapshot feature is missing, it is normal that bcachefs has better performance. The snapshot capability has a big impact on the performance (e.g. each block have a reference counter which has to be update, when a block is created, changed or deleted). I think that we could discuss about the bcachefs performance after it has a comparable set of feature.

SUSE reaffirms support for Btrfs

Posted Aug 30, 2017 0:33 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link] (1 responses)

That's just silly - you're assuming one approach to implementing snapshots, which has little to do with how they're going to be implemented in bcachefs.

Anyways, snapshots aren't the only feature users care about. At this rate, bcachefs is going to have proper working RAID before btrfs.

SUSE reaffirms support for Btrfs

Posted Aug 30, 2017 16:59 UTC (Wed) by kreijack (guest, #43513) [Link]

> That's just silly - you're assuming one approach to implementing snapshots, which has little to do with
> how they're going to be implemented in bcachefs.

You are right when you say that I don't know the bcachefs internal, however it still not correct to compare the speed of filesystems when the features aren't comparable.

Anyway I am curious how the snapshot are implemented in bcachefs. Could you share with us more details ? How is scalable the bcachefs solution (btrfs behave well with ~100 snapshots, and with some limits is tolerant with 1000 snapshots)

> Anyways, snapshots aren't the only feature users care about.
> At this rate, bcachefs is going to have proper working RAID before btrfs.

I can't comment about prediction. I hope that bcachefs will be a good filesystem.
Anyway on of the biggest problem in BTRFS is the huge number of features and their combinations. The most difficult thing is verify that BTRFS behave "not so bad" in every combination.