1. 36
  1.  

  2. 21

    Kent “tried” merging it since 2019 [0]

    Even thought he said it’s “done cooking” EC Support wasn’t implemented at that time and is today still half baked (imho), zstd background compression is still broken (afaik).

    The second try [1] ignored standard formatting, didn’t break it up into smaller commits and had some other issues. It feels to me as if he didn’t really want to get it merged…. Anyway since then there were quite a few big changes like finally implementing snapshots, the whole on disk format change for the snapshots, another disk format change, oh and now quota support is broken.

    Of annoyance is also that the (hidden) fuse option in the bcachefs tools is broken for some time now (since snapshots), that the fsck utility is not as good as it could be and that there seem to be quite some bugs (mostly EC afaict) [2]. Imho not a good track record. Another gripe I have is that it by default takes 10% of your disk capacity (~8% should be reserved for GC)

    Anyway you can take a look at his patreon [3], because even after all that I said I still drive a custom kernel with bcachefs support. I like the idea of a FS actually standing on the shoulders of giants instead of blindly imitating or stupidly fighting them. Hopefully bcachefs will not need another on disk format change after it was merged like some other fs [4] (note to btrfs I’m really excited about the format change for btrfs, but a bit scared at the same time. I hope that it solves a long standing performance bottleneck I have)

    [0] http://lkml.iu.edu/hypermail/linux/kernel/1906.1/02169.html

    [1] https://lkml.org/lkml/2020/12/13/284

    [2] https://github.com/koverstreet/bcachefs/issues

    [3] https://www.patreon.com/bcachefs/posts

    [4] https://josefbacik.github.io/kernel/btrfs/extent-tree-v2/2021/11/10/btrfs-global-roots.html

    1. 2

      Another gripe I have is that it by default takes 10% of your disk capacity (~8% should be reserved for GC)

      Do you mean that of the 10% it “steals”, 8% is for GC and 2% is for other stuff, or that 10% is in your opinion too much and it should only be 8%?

      1. 1

        I mean it reserves 10% of your disk capacity 8% of the total space is for gc. You can limit that at creation to 5%.

        I can check the exact reservations amd it’s uses tomorrow if you are intereatwd.

    2. 5

      The link lives on pages deeper down, so here’s the repo if anyone’s interested https://evilpiepirate.org/git/bcachefs.git/log/

      I’ve been following it for a while (and supporting at https://www.patreon.com/bcachefs ). I really hope that it gets to see production use one day. The developer behind it is really consistent with the effort.

      1. 2

        In Linux tradition, if it is any good, it will likely not get merged.

        1. 8

          What are some examples of this?

            1. 1

              Reiser4 is the first one that comes to mind.

              Tux3 is another.

            2. 7

              Why do you think so? It’s already been through one round of reviews and some of the required building blocks have been merged.

              1. 2

                NTFS3 was merged.

            3. 5

              That’s not how you spell ZFS.

              Bcachefs is too new and unproven. It will eat your data if you let it by using it.

              1. 10

                Bcachefs is intended to succeed the current go-to options: Btrfs and ZFS. All filesystems have to start somewhere.

                1. 4

                  Is there a guide what are the planned improvements over ZFS?

                  1. 9

                    Apparently it has a much smaller codebase than ZFS or btrfs (and in fact, it’s slightly smaller than ext4) while being cleaner and more flexible.

                    1. 6

                      Not a technical improvement, but if all goes right, it would be included in mainline kernel with a known-valid licence - which I don’t think zfs will ever achieve.

                      1. 4

                        Not a technical improvement, but if all goes right, it would be included in mainline kernel with a known-valid licence - which I don’t think zfs will ever achieve.

                        …on Linux, at least ;)

                        1. 3

                          At the same time it seems to be GLPv2 licensed, which mean that merge into BSDs is also something that we probably will not see. So almost all users of ZFS will not bother with it.

                          1. 2

                            Maybe that’s for the best. Both worlds can have great filesystems, and the two worlds don’t need to use the same great filesystems. I’m getting more and more convinced that the less BSD people and Linux people have to interact, the better.

                            1. 1

                              I’m still hopeful once HAMMER2 is more mature, it’ll get ported to other systems including Linux.

                      2. 3

                        To me, two things stands out comparing to ZFS (at least promised):

                        1. True tiered storage support, unlike current L2ARC / slog in ZFS;

                        2. Better expansion RAIDZ* disks.

                        1. 1

                          Number one is 100% correct, and no one should use an slog thinking it’s tiered storage. The only tiered storage ZFS does is tier-0 in memory (ARC, not L2ARC) and tier-1 to your pool, rate-limited by the slowest vdev. The ZFS devs have turned down requests for true tiered storage many times, so I don’t think it’s going to happen anytime in the next 5 years. (You can get it working by using ZFS with a dm-writecache device as the underlying “disk” but I think all bets are probably off as to the integrity of the underlying data.)

                          But for number two, draid is probably the correct answer. I think it’s superior to what bcachefs is offering.

                      3. 2

                        But why not use what’s there. ZFS or porting HAMMER instead? If your focus is “reliability and robustness” code that is used in production seems better than creating new code with new bugs.

                        1. 3

                          But why not use what’s there. ZFS or porting HAMMER instead? If your focus is “reliability and robustness” code that is used in production seems better than creating new code with new bugs.

                          Because licenses, to start somewhere (the Linux kernel can’t include BSD code, for example). It’s also hard to argue that HAMMER is proven due to it’s extremely small user base, even if it might be interesting from a technical standpoint.

                          1. 6

                            Linux can include BSD licensed code - as long as there’s no advertising clause, it’s compatible with GPL.

                            See an old thread: http://lkml.iu.edu/hypermail/linux/kernel/0003.0/1322.html

                            1. 1

                              Linux can include BSD licensed code - as long as there’s no advertising clause, it’s compatible with GPL.

                              I stand corrected!

                              1. 1

                                This is true, but note that ZFS is CDDL, not BSD.See https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

                                …but HAMMER would be fine from a license perspective.

                              2. 4

                                the Linux kernel can’t include BSD code, for example

                                What makes you think so? There’s quite a bit of code in the Linux kernel that started out BSD licensed.

                                1. 2

                                  It’s totally legal to go either direction (BSD code mixed with GPL code or GPL code mixed with BSD code). There is a cultural stigma against the other license, depending on which license camp one is in. I.e. Most BSD people dislike the GPL license and go out of their way to replace GPL’d code with BSD license code(and the opposite for BSD code in Linux land).

                                  As a more recent example, GUIX didn’t get invented out of a vacuum, it’s partly(mostly?) GPL people unhappy with the Nix license.

                                  One extra gotcha as @singpolyma points out, GPL code mixed with BSD code enforces the GPL license on the binaries, usually making BSD proponents unhappy.

                                  1. 3

                                    This is very misleading because if you add GPL to BSD then the combined work/a derived work can no longer be distributed as BSD.

                                2. 2

                                  the Linux kernel can’t include BSD code

                                  BSD is GPL-compatible, but the reverse isn’t true: BSD code can’t include GPL’d code.

                                  1. 2

                                    Technically BSD codebases can include all the GPL’d code they want. They can even keep the BSD license on the parts that don’t depend on the GPL part. The binaries would be GPL though and there are other reasons purists might avoid this.

                                  2. 1

                                    due to it’s extremely small user base

                                    So, like, bcachefs? or nilfs2 (which is in mainline…).

                            2. 2

                              I’m digging the architecture document. It’s always interesting to see the details of complex systems based on b-trees. (Apple’s legacy HFS+ is another.)

                              1. 2

                                ZSTD support unfortunately still seems to be slightly buggy

                                Does this “buggy” mean eatmydata? One of the major reason people use ZFS is raidz1/raidz2, supporting R0/1 only isn’t very friendly for consumers, and I bet enterprise won’t take it either due to lack of age.

                                1. 1

                                  Is this still on track to get merged into the kernel?

                                  Stories with similar links:

                                  1. bcachefs: The COW filesystem that won't eat your data via pushcx 4 years ago | 16 points | 2 comments