4 ms·

That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers. In fact they deliver

That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers. In fact they delivered the erasure coding for parity raid back in march this year. The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is. I can only tell you that mixing different device tiers and having a per-file/directory replication setting is a god send specially in these times where storage costs more than gold.

tarruda 7d ago
> The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is. I'm pretty sure Bcachefs is amazing and better than Btrfs. I also think Zfs is amazing and better than Btrfs. Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. > That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers. A better approach might have been to just paused mainline merging instead of forcing being kicked out? Eg "Hey Linus, Bcachefs is still in early development and I need to merge changes in a pace that is not compatible with Linux development process. So I'm going to pause for a while now and once it reaches maintenance status I will focus on submitting patches in a healthy pace that you can digest".
- irusensei 7d ago
  I think in a perfect world they should had put someone in between to mediate and curate patches while providing DKMS for urgent patches. As for BTRFS I think its also pretty good. Its just that I have the impression its development is guided by the needs of its sponsors and sadly for us META doesn't need RAID5.
  - koverstreet 7d ago
    Meta doesn't have anyone working on btrfs anymore, it appears to be two guys at SuSE and drive bys.
    - nolist_policy 6d ago
      Not true, Boris Burkov from Meta works on btrfs. And two people from WDC.
      - koverstreet 6d ago
        Within the last year? I think bcachefs is going to be overtaking btrfs soon on active developers, from the trends I saw in the commit logs
- koverstreet 7d ago
  I was very up front about where we were at. A lot of things were tried, people did try to mediate. The particularly galling thing though was when I finally started looking - post split - comparing bcachefs PRs to other subsystems and especially XFS - I was being more conservative with what I considered a critical bugfix. There was never a clear statement on what the issue was. What you guys got in public was about as much as I got. All I can say is - going fast when you're stabilizing and getting bugfixes out the door is what you can and should be doing when you've invested in test coverage, test automation, keeping the codebase clean and asserted, and building up a community that works well together on testing and shaking things out. I genuinely do not know what they were thinking.
  - locknitpicker 6d ago
    > There was never a clear statement on what the issue was. What you guys got in public was about as much as I got. If you are referring to why bcachefs was removed from the Linux kernel, here's a discussion on bcachefs being removed from the Linux kernel. https://news.ycombinator.com/item?id=44868868 https://news.ycombinator.com/item?id=44868868
    - ssl-3 6d ago
      I'd like to point out that HN user koverstreet was involved in those threads, here. They already know what was discussed. (Good? Bad? Indifferent? I don't know and I don't have a dog in this race. I'm just here connecting the dots.)
      - locknitpicker 5d ago
        > I'd like to point out that HN user koverstreet was involved in those threads, here. Yes, that's why those remarks on how it's a mystery how bcachefs was pulled from the kernel are perplexing. To me they sound like gaslighting.
  - r0l1 6d ago
    Just pleases try to get it back into mainline.
- nvme0n1p1 7d ago
  > Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. 100%. My system is rock solid and the last thing I need is rolling the dice after every update on whether my system will boot. https://www.reddit.com/r/archlinux/comments/eywcp7/linux_551_broke_zfs_cannot_boot/ https://www.reddit.com/r/archlinux/comments/eywcp7/linux_551... I'm impressed with bcachefs's accomplishments though, and if they ever reconcile with the kernel I'll surely give it a fair shake.
  - koverstreet 7d ago
    bcachefs on Arch is a bit better supported, we have the distro package maintainer in the bcachefs IRC channel, and I've never lagged on mainline support like ZFS has. Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.
  - andriy_koval 6d ago
    btrfs has one critical issue they don't fix: it blocks access to fs for minutes if you remove large files. I am not sure how this is acceptable for prod grade fs..
    - nolist_policy 6d ago
      Only if you have quotas enabled IIRC.
      - andriy_koval 6d ago
        no quota enabled
    - simoncion 6d ago
      > it blocks access to fs for minutes if you remove large files. How large is large? I've deleted files with sizes of tens to hundreds of GBs and not seen that, and can probably whip up a test with a single-digit TB file if motivated. Do you perhaps have 'discard=sync' in your mount options, or are using a kernel earlier than 6.2, which is the version -according to the docs- where async discard became the default?
- ssl-3 7d ago
  > I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. I used to think that about ReiserFS, too. It was in the mainline kernel, development was snappy, and it solved some performance problems. I used it all over the place. Things then subsequently... changed. :-/
  - bjoli 6d ago
    You had plenty of time to move away from reiserfs. Something like 15 years between the conviction and removal.
- doubled112 7d ago
  > I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. Except RHEL. They don’t include it in their kernels. Alma Linux started including it again though. It can never be easy.
  - cromka 6d ago
    Came here to say this. Supposedly Fedora also considers giving up on it.
    - farlight 6d ago
      This sounds like FUD, do you have any references? Genuinely asking. I follow LWN reporting religiously, which in turn follows Fedora development (and associated drama) closely, and haven't seen anything said in this direction. Just had a quick look on LWN and Fedora development resources, and nothing came up.
      - cromka 5d ago
        This is what I read here and elsewhere bunch of times, which is why I said "supposedly". A quick search did not reveal any meaningful proof, though. I'll ask next time I hear someone say this.
    - em-bee 6d ago
      unlikely. reference please. btrfs was the default filesystem on fedora installs last time i checked. to remove it they would have to first change that, then give it a few years before even considering removing it from the kernel. redhat could remove it because it was never default and never recommended.
      - cromka 5d ago
        This is what I read here and elsewhere bunch of times, which is why I said "supposedly". A quick search did not reveal any meaningful proof, though. I'll ask next time I hear someone say this.
novafunc 7d ago
bcachefs was already working at its own pace prior to being accepted in the kernel. It could have continued doing so for years until it was really "ready". Instead it got kicked out because Kent constantly ignored the kernel's contribution rules and is unlikely it will ever be accepted back into the kernel.
- irusensei 7d ago
  That would be a shame since there is nothing else over there with the same set of features. Disregarding drama, I'm telling you it’s that good.
- koverstreet 7d ago
  I'd really appreciate it if we could drop the FUD over contribution rules. There are no such rules, it is explicitly Linus's way or the highway, and I already replied to that elsewhere. And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum. A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up. Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.
  - pantalaimon 7d ago
    You can't let Reddit guide your technical decisions. The FS was marked experimental, so there is no urgency in fixing bugs or providing features in a certain cycle. Everyone using it knows what they got themselves into. You can still provide the DKMS module for faster fixes and features for anyone who wants to use BCacheFS more seriously for the time that the upstreaming process takes, but eventually it would have all been on mainline. Asahi is taking a similar approach where they have their downstream kernel and push things upstream once they are mature. That means the upstream kernel is not useful for running on that hardware now, but things are moving there eventually.

tarruda 7d ago

> The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is. I'm pretty sure Bcachefs is amazing and better than Btrfs. I also think Zfs is amazing and better than Btrfs. Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. > That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers. A better approach might have been to just paused mainline merging instead of forcing being kicked out? Eg "Hey Linus, Bcachefs is still in early development and I need to merge changes in a pace that is not compatible with Linux development process. So I'm going to pause for a while now and once it reaches maintenance status I will focus on submitting patches in a healthy pace that you can digest".

irusensei 7d ago
I think in a perfect world they should had put someone in between to mediate and curate patches while providing DKMS for urgent patches. As for BTRFS I think its also pretty good. Its just that I have the impression its development is guided by the needs of its sponsors and sadly for us META doesn't need RAID5.
- koverstreet 7d ago
  Meta doesn't have anyone working on btrfs anymore, it appears to be two guys at SuSE and drive bys.
  - nolist_policy 6d ago
    Not true, Boris Burkov from Meta works on btrfs. And two people from WDC.
    - koverstreet 6d ago
      Within the last year? I think bcachefs is going to be overtaking btrfs soon on active developers, from the trends I saw in the commit logs
koverstreet 7d ago
I was very up front about where we were at. A lot of things were tried, people did try to mediate. The particularly galling thing though was when I finally started looking - post split - comparing bcachefs PRs to other subsystems and especially XFS - I was being more conservative with what I considered a critical bugfix. There was never a clear statement on what the issue was. What you guys got in public was about as much as I got. All I can say is - going fast when you're stabilizing and getting bugfixes out the door is what you can and should be doing when you've invested in test coverage, test automation, keeping the codebase clean and asserted, and building up a community that works well together on testing and shaking things out. I genuinely do not know what they were thinking.
- locknitpicker 6d ago
  > There was never a clear statement on what the issue was. What you guys got in public was about as much as I got. If you are referring to why bcachefs was removed from the Linux kernel, here's a discussion on bcachefs being removed from the Linux kernel. https://news.ycombinator.com/item?id=44868868 https://news.ycombinator.com/item?id=44868868
  - ssl-3 6d ago
    I'd like to point out that HN user koverstreet was involved in those threads, here. They already know what was discussed. (Good? Bad? Indifferent? I don't know and I don't have a dog in this race. I'm just here connecting the dots.)
    - locknitpicker 5d ago
      > I'd like to point out that HN user koverstreet was involved in those threads, here. Yes, that's why those remarks on how it's a mystery how bcachefs was pulled from the kernel are perplexing. To me they sound like gaslighting.
- r0l1 6d ago
  Just pleases try to get it back into mainline.
nvme0n1p1 7d ago
> Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. 100%. My system is rock solid and the last thing I need is rolling the dice after every update on whether my system will boot. https://www.reddit.com/r/archlinux/comments/eywcp7/linux_551_broke_zfs_cannot_boot/ https://www.reddit.com/r/archlinux/comments/eywcp7/linux_551... I'm impressed with bcachefs's accomplishments though, and if they ever reconcile with the kernel I'll surely give it a fair shake.
- koverstreet 7d ago
  bcachefs on Arch is a bit better supported, we have the distro package maintainer in the bcachefs IRC channel, and I've never lagged on mainline support like ZFS has. Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.
- andriy_koval 6d ago
  btrfs has one critical issue they don't fix: it blocks access to fs for minutes if you remove large files. I am not sure how this is acceptable for prod grade fs..
  - nolist_policy 6d ago
    Only if you have quotas enabled IIRC.
    - andriy_koval 6d ago
      no quota enabled
  - simoncion 6d ago
    > it blocks access to fs for minutes if you remove large files. How large is large? I've deleted files with sizes of tens to hundreds of GBs and not seen that, and can probably whip up a test with a single-digit TB file if motivated. Do you perhaps have 'discard=sync' in your mount options, or are using a kernel earlier than 6.2, which is the version -according to the docs- where async discard became the default?
ssl-3 7d ago
> I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. I used to think that about ReiserFS, too. It was in the mainline kernel, development was snappy, and it solved some performance problems. I used it all over the place. Things then subsequently... changed. :-/
- bjoli 6d ago
  You had plenty of time to move away from reiserfs. Something like 15 years between the conviction and removal.
doubled112 7d ago
> I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part. Except RHEL. They don’t include it in their kernels. Alma Linux started including it again though. It can never be easy.
- cromka 6d ago
  Came here to say this. Supposedly Fedora also considers giving up on it.
  - farlight 6d ago
    This sounds like FUD, do you have any references? Genuinely asking. I follow LWN reporting religiously, which in turn follows Fedora development (and associated drama) closely, and haven't seen anything said in this direction. Just had a quick look on LWN and Fedora development resources, and nothing came up.
    - cromka 5d ago
      This is what I read here and elsewhere bunch of times, which is why I said "supposedly". A quick search did not reveal any meaningful proof, though. I'll ask next time I hear someone say this.
  - em-bee 6d ago
    unlikely. reference please. btrfs was the default filesystem on fedora installs last time i checked. to remove it they would have to first change that, then give it a few years before even considering removing it from the kernel. redhat could remove it because it was never default and never recommended.
    - cromka 5d ago
      This is what I read here and elsewhere bunch of times, which is why I said "supposedly". A quick search did not reveal any meaningful proof, though. I'll ask next time I hear someone say this.

novafunc 7d ago

bcachefs was already working at its own pace prior to being accepted in the kernel. It could have continued doing so for years until it was really "ready". Instead it got kicked out because Kent constantly ignored the kernel's contribution rules and is unlikely it will ever be accepted back into the kernel.

irusensei 7d ago
That would be a shame since there is nothing else over there with the same set of features. Disregarding drama, I'm telling you it’s that good.
koverstreet 7d ago
I'd really appreciate it if we could drop the FUD over contribution rules. There are no such rules, it is explicitly Linus's way or the highway, and I already replied to that elsewhere. And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum. A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up. Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.
- pantalaimon 7d ago
  You can't let Reddit guide your technical decisions. The FS was marked experimental, so there is no urgency in fixing bugs or providing features in a certain cycle. Everyone using it knows what they got themselves into. You can still provide the DKMS module for faster fixes and features for anyone who wants to use BCacheFS more seriously for the time that the upstreaming process takes, but eventually it would have all been on mainline. Asahi is taking a similar approach where they have their downstream kernel and push things upstream once they are mature. That means the upstream kernel is not useful for running on that hardware now, but things are moving there eventually.