Btrfs Async Buffered Writes Slated For Linux 6.1 - 2x Throughput Improvement

[_ReD_]

btrfs cant hold a candle to Tectonic (backed by xfs as explained in that document).

Apples and oranges, anyone? Btrfs is not a distributed filesystem/object-store. Not at all.
How (and why) would anyone compare it to one, is besides me.

Furthermore Facebook VMs have their own root images on local hardware for performance and scalability reasons.
It's the humongous amount of platform data that resides on tectonic: https://www.youtube.com/watch?v=U7gXR2L05IU

[_ReD_]

.. stop using Meta/FB as justification for using btrfs. Their usage of btrfs is not at all comparable.

Explain why not, in a pinch?

[_ReD_]

Theoretically everything is a potential source of corruptions. What's your point?
For home users 9 out of 10 times a raid solution makes no sense. Main goal is to unionize drives. Makes no sense to use raid for that while you can simply do it on user level, with MergerFS. Much cheaper and easier solution. It does not introduce extra risks.

MergerFS is rather simple and probably ok, but it's not really widely tested and BTRFs can directly span multiple devices for free and much more efficiently (as can zfs and LVM).
Some discussion: https://www.google.com/search?q=btrfs+vs+lvm

[zexelon]

Oh, but they do, and very much so.
ave a read: https://www.google.com/search?q=facebook+usage+of+btrfs

LOL I see that the local timezone must have reached "free time" for you Kudos on reading through this whole mud-wrestling fest!

With regards to the link you put, its a link to a google search... it has absolutely nothing to say on Facebook running btrfs on bare metal. In fact the first link (https://facebookmicrosites.github.io...-facebook.html) is probably the most interesting though undated. Basically it indicates the primary use case of btrfs is within Tupperware, their container management system. Basically its using btrfs to take snapshots of a gold image to create an isolated container filesystem more efficiently. Arguably you can do the exact same thing with LVM thin-provisioning but whatever.

It does not indicate even here that its running on bare metal in any way.

[_ReD_]

IME it's almost impossible to lose data with btrfs. Even when doing really stupid shit like mounting it twice at the same time (in a VM with passed through disk, or mounting it while it's still mounted on a hibernated system) or when accidentally wiping a dirty bcache cache. In almost all cases "btrfs restore" will get your data back without issues. It's very reliable.

Yeah, about that... that's a pain point right there!
BTRFS sorely needs a "fix in place" tool that works.

Having to "btrfs restore*" for every small problem is far from optimal. (* which implies: restore to another disk, reformat, restore again... and still deal with the aftermath.)
Conversely, a quick pass of an fsck-alike, which tends to consistently do the right thing (as on ext4) would be much more convenient, in a pinch.

[_ReD_]

It does not indicate even here that its running on bare metal in any way.

First of all, it does indicate that it's running on bare metal — and very much so — eg:
https://youtu.be/U7gXR2L05IU?t=432 (4:32 and minute 26 and 32 and 35:45 and 44:50 and 45:30 and 48:18)

Second: even if it wasn't running on bare metal, what would that bring to your point anyway?

[zexelon]

And what if it doesn't? What would that bring to your point anyway?

Again it does not matter what Facebook does, please refer back to post #28... the premise is, stop using Facebook as justification to run anything on btrfs.

[_ReD_]

Again it does not matter what Facebook does, please refer back to post #28... the premise is, stop using Facebook as justification to run anything on btrfs.

Then the premise is preposterous and wrong. Or shall I concede... just misinformed?


p.s. I edited comment 97 to better address this all.

[F.Ultra]

How many *years* now has it been, with zero progress on the structural issue that make BRTFS raid fundamentally unusable?

Note that you speak specifically about raid5 and not btrfs raid, there are close to zero work being done on raid5 due to there being close to zero interest from the users to use raid5. BTRFS with raid1 (and10) has been stable for decades and is also where the large use base is.

I don't know to do either.

I don't know who the maintainer is and definitely can't bump it myself.

The zstd maintainer in the Linux Kernel is Nick Terrell [email protected] who AFAIK is also the zstd dev upstream at FaceBook. So that he have still not pushed a newer version of ztstd to the kernel (the zstd code is not for btrfs alone) looks like FB themselves not seeing 1.5 as being stable enough yet for inclusion.

[zexelon]

Then the premise is preposterous and wrong. Or shall I concede... just misinformed?


p.s. I edited comment 97 to better address this all.

Honestly I am just enjoying the back and forth aggressiveness that so wonderfully permeates the Linux community. I have personally used btrfs but ended up going to xfs due to the nature of the systems I am managing.

For most of my personal management I have gone to LVM as i found it easier to manage and due to its longer life better supported in some of the tooling I used. Even then I have largely dumped all of this for just running everything in vms backed by qcow files with snapshotting and gold images.

I have learned a TON in this thread about Facebooks internal systems, so that's been fun!