4 ms·

And a honking great bus factor of Kent deciding enough is enough and having a tantrum. You couldn't and shouldn't trust critical data to such a scenario

by rob_c 1y ago

bombcar 1y ago
There’s no harm doing it - if the thing actually works! Kent getting that lass metro pass wouldn’t cause your file system to immediately corrupt and delete itself. What you want to avoid is becoming dependent on continued development of it - but unless you’re particularly using some specific feature of the file system that none other provide you’ll have time to migrate off it. Even resierfs didn’t cease to operate.
- tremon 1y ago
  The reiserfs code was stable and in maintenance mode. All new development effort was going into reiser4, which absolutely did die off. IIRC a few developers (that were already working on it) tried to continue the development, but it was abandoned due to lack of support and funds. In terms of maturity, bcachefs is closer to production quality than reiser4 was, but it's still closer to reiser4 than reiserfs in its lifecycle.
  - koverstreet 1y ago
    we're further along than btrfs in "will it keep my data"
    - tremon 1y ago
      Fair enough, I have no practical experience with bcachefs myself.
      - koverstreet 1y ago
        Fair :) I've been trying to keep this thing (relatively) quiet and low profile until it's completely done, but it's gotten hyped. Data integrity, core IO paths, all the failure modes, all the crazy repair corner cases - these are the hard parts if you really want to get a filesystem right. These are what we've been taking our time on. I can't claim 100% success rate w.r.t. data loss, but it's been phenomenally good, with some crazy stories of filesystems we've gotten back that you'd never expect - and then it just becomes the norm. I love the crazy bug reports that really push the boundaries of our capabilities. That's an attitude that reiserfs and btrfs never had, and when I am confident that it is 100% rock solid and bulletproof I'll be lifting the experimental label.
      - sroussey 1y ago
        > I have no practical experience with bcachefs myself. Who does? When the MySQL and Postgres projects recommend it, I’ll have a look.
        koverstreet 1y ago
        That's still a ways off, but it is worth noting that bcachefs handles database workloads in cow mode with no issue.
    - jcalvinowens 1y ago
      > we're further along than btrfs in "will it keep my data" Honestly Kent, this continuing baseless fearmongering from you about btrfs is absolutely disgusting. It costs you. I was initially very interested in bcachefs, but I will never spend my time testing it or contributing to it as long as you continue behave this way. I'm certain there are many many others who would nominally be very interested, but feel the same way I do. Your filesystem charitably gets 0.001% the real world testing btrfs does. To claim it is more reliable than btrfs is ignorant and naive. Maybe it actually is more reliable in the real world (press X to doubt...), but you can't possibly know yet, and you won't know for a long time.
      - rob_c 1y ago
        I'm happy to support that bcache may have a stable on disk format, but the lashing out at the alternatives is another example of behaviour I'd prefer to see dropped. If your product is so great its it's own advert. If it has problems spend the limited person power fixing it not attacking the opposition, this is what ciq have done, do better.
      - koverstreet 1y ago
        We have documented, in this very thread, issues with multi device setups that btrfs has that bcachefs does not - and btrfs developers ignoring these issues. This isn't baseless fearmongering, this is "did you think through the failure modes when you were designing the basics". This stuff comes up over, and over, and over. Engineering things right matters, and part of that absolutely is comparing and documenting approaches and solutions to see what went right and what went wrong. This isn't a popularity contest, and this isn't high school where we form into cliques and start slinging insults. Come up with facts, documentation, analysis. That's what we do. I'm tired of these threads degenerating into flamewars.
        kzrdude 1y ago
        (That's impressive, but the real world user pool is much smaller isn't. It still sounds like a proud brag more than it does proven by workload.) I am not a filesystems guy, but I was disappointed when I realized that btrfs did not have a good design for ENOSPC handling. So I'm curious, does bcachefs design for a benign failure mode when out of space?
    - bombcar 1y ago
      From my experience as a [x,z]fs snob, "further along than butterfs" is damning with faint praise.
    - bigyabai 1y ago
      I have used BTRFS for 6 years on 5 drives without a single journaled corruption.
      - pmarreck 1y ago
        And I used it for 2 years on 2 drives on 2 different OS'es (Manjaro and Arch) and had 2 corruptions that bricked the drives. And they were root filesystems, so... that wasn't fun. Statistics are funny like that.
        taskforcegemini 1y ago
        bricked the drive as in the disk was physically defective? disks like to brick on their own, how sure are you btrfs was the reason?
    - int_19h 1y ago
      btrfs is used by numerous NAS providers at this point.
      - koverstreet 1y ago
        Do you know any that use it in multi device mode?
        int_19h 1y ago
        Synology. (Yes, I know they don't do it "the right way". It still works at the end of the day.)
        koverstreet 1y ago
        No, we're talking about btrfs multi device mode, md doesn't count :)
        int_19h 1y ago
        Are we? You did not qualify your original statement about btrfs "not keeping data" with that.
    - pmarreck 1y ago
      Hi, I believe I've contributed financially to your project in the past (mainly because zfs (licensing issues) and btrfs (unreliability, in my personal experience) need good competition... and btrfs bricked 2 of my drives once...) You've built an amazing thing but speaking as another very opinionated dev on the outside who sometimes butts heads with other opinionated devs- please just defer to Linus on this so you can get this in the kernel. Or just have it pushed to the next kernel release (I realize this has already happened repeatedly). Just please don't add a significant feature in a bugfix cycle. And (as mercurial as we all know he is, and as valid as some of your concerns surely are), try to keep the peace with that guy. Do it for the sake of the project. I've been waiting for this to drop for literally years now. I care about it, and I know no one does more than you, and I swear that I know exactly what that's like. It's your brain-baby, the concrete instantiation of your blood/sweat/tears. But... Take a deep breath, swallow, trust the process. The bands that produced some of the best music had HUGE tensions within them. But you can't let it explode (we all know that some bands did). I made that mistake a year ago, and lost a job I very much cared about. (Perhaps to a fault.) Don't be me. lol
- rob_c 1y ago
  > There’s no harm doing it - if the thing actually works This is the antiphrasis of good project management and stability. No you want to avoid a static target in a dynamic environment that is unmaintained (such as an experimental fs in the kernel tree). If it's static and unsupported. You'd end up failing to be run this to recover disks using ryzen9 processors that requires a minimum kernel version where the API/abi have drifted so far that the old module won't compile or import. If you can't afford to get your hands dirty and hack at the API changing if this has such a bus factor. DON'T USE IT. Frankly the argument you're making is the other side of stick with ext2 since it works. It's probably going to die soon and frankly unless there's a community to support it. (such as zfs, or ext4 in the kernel, or CEPH in hpc corporate spaces)

And a honking great bus factor of Kent deciding enough is enough and having a tantrum. You couldn't and shouldn't trust critical data to such a scenario

by rob_c 1y ago

And a honking great bus factor of Kent deciding enough is enough and having a tantrum. You couldn't and shouldn't trust critical data to such a scenario

bombcar 1y ago

There’s no harm doing it - if the thing actually works! Kent getting that lass metro pass wouldn’t cause your file system to immediately corrupt and delete itself. What you want to avoid is becoming dependent on continued development of it - but unless you’re particularly using some specific feature of the file system that none other provide you’ll have time to migrate off it. Even resierfs didn’t cease to operate.

tremon 1y ago
The reiserfs code was stable and in maintenance mode. All new development effort was going into reiser4, which absolutely did die off. IIRC a few developers (that were already working on it) tried to continue the development, but it was abandoned due to lack of support and funds. In terms of maturity, bcachefs is closer to production quality than reiser4 was, but it's still closer to reiser4 than reiserfs in its lifecycle.
- koverstreet 1y ago
  we're further along than btrfs in "will it keep my data"
  - tremon 1y ago
    Fair enough, I have no practical experience with bcachefs myself.
    - koverstreet 1y ago
      Fair :) I've been trying to keep this thing (relatively) quiet and low profile until it's completely done, but it's gotten hyped. Data integrity, core IO paths, all the failure modes, all the crazy repair corner cases - these are the hard parts if you really want to get a filesystem right. These are what we've been taking our time on. I can't claim 100% success rate w.r.t. data loss, but it's been phenomenally good, with some crazy stories of filesystems we've gotten back that you'd never expect - and then it just becomes the norm. I love the crazy bug reports that really push the boundaries of our capabilities. That's an attitude that reiserfs and btrfs never had, and when I am confident that it is 100% rock solid and bulletproof I'll be lifting the experimental label.
    - sroussey 1y ago
      > I have no practical experience with bcachefs myself. Who does? When the MySQL and Postgres projects recommend it, I’ll have a look.
      - koverstreet 1y ago
        That's still a ways off, but it is worth noting that bcachefs handles database workloads in cow mode with no issue.
  - jcalvinowens 1y ago
    > we're further along than btrfs in "will it keep my data" Honestly Kent, this continuing baseless fearmongering from you about btrfs is absolutely disgusting. It costs you. I was initially very interested in bcachefs, but I will never spend my time testing it or contributing to it as long as you continue behave this way. I'm certain there are many many others who would nominally be very interested, but feel the same way I do. Your filesystem charitably gets 0.001% the real world testing btrfs does. To claim it is more reliable than btrfs is ignorant and naive. Maybe it actually is more reliable in the real world (press X to doubt...), but you can't possibly know yet, and you won't know for a long time.
    - rob_c 1y ago
      I'm happy to support that bcache may have a stable on disk format, but the lashing out at the alternatives is another example of behaviour I'd prefer to see dropped. If your product is so great its it's own advert. If it has problems spend the limited person power fixing it not attacking the opposition, this is what ciq have done, do better.
    - koverstreet 1y ago
      We have documented, in this very thread, issues with multi device setups that btrfs has that bcachefs does not - and btrfs developers ignoring these issues. This isn't baseless fearmongering, this is "did you think through the failure modes when you were designing the basics". This stuff comes up over, and over, and over. Engineering things right matters, and part of that absolutely is comparing and documenting approaches and solutions to see what went right and what went wrong. This isn't a popularity contest, and this isn't high school where we form into cliques and start slinging insults. Come up with facts, documentation, analysis. That's what we do. I'm tired of these threads degenerating into flamewars.
      - kzrdude 1y ago
        (That's impressive, but the real world user pool is much smaller isn't. It still sounds like a proud brag more than it does proven by workload.) I am not a filesystems guy, but I was disappointed when I realized that btrfs did not have a good design for ENOSPC handling. So I'm curious, does bcachefs design for a benign failure mode when out of space?
  - bombcar 1y ago
    From my experience as a [x,z]fs snob, "further along than butterfs" is damning with faint praise.
  - bigyabai 1y ago
    I have used BTRFS for 6 years on 5 drives without a single journaled corruption.
    - pmarreck 1y ago
      And I used it for 2 years on 2 drives on 2 different OS'es (Manjaro and Arch) and had 2 corruptions that bricked the drives. And they were root filesystems, so... that wasn't fun. Statistics are funny like that.
      - taskforcegemini 1y ago
        bricked the drive as in the disk was physically defective? disks like to brick on their own, how sure are you btrfs was the reason?
  - int_19h 1y ago
    btrfs is used by numerous NAS providers at this point.
    - koverstreet 1y ago
      Do you know any that use it in multi device mode?
      - int_19h 1y ago
        Synology. (Yes, I know they don't do it "the right way". It still works at the end of the day.)
        koverstreet 1y ago
        No, we're talking about btrfs multi device mode, md doesn't count :)
        int_19h 1y ago
        Are we? You did not qualify your original statement about btrfs "not keeping data" with that.
  - pmarreck 1y ago
    Hi, I believe I've contributed financially to your project in the past (mainly because zfs (licensing issues) and btrfs (unreliability, in my personal experience) need good competition... and btrfs bricked 2 of my drives once...) You've built an amazing thing but speaking as another very opinionated dev on the outside who sometimes butts heads with other opinionated devs- please just defer to Linus on this so you can get this in the kernel. Or just have it pushed to the next kernel release (I realize this has already happened repeatedly). Just please don't add a significant feature in a bugfix cycle. And (as mercurial as we all know he is, and as valid as some of your concerns surely are), try to keep the peace with that guy. Do it for the sake of the project. I've been waiting for this to drop for literally years now. I care about it, and I know no one does more than you, and I swear that I know exactly what that's like. It's your brain-baby, the concrete instantiation of your blood/sweat/tears. But... Take a deep breath, swallow, trust the process. The bands that produced some of the best music had HUGE tensions within them. But you can't let it explode (we all know that some bands did). I made that mistake a year ago, and lost a job I very much cared about. (Perhaps to a fault.) Don't be me. lol
rob_c 1y ago
> There’s no harm doing it - if the thing actually works This is the antiphrasis of good project management and stability. No you want to avoid a static target in a dynamic environment that is unmaintained (such as an experimental fs in the kernel tree). If it's static and unsupported. You'd end up failing to be run this to recover disks using ryzen9 processors that requires a minimum kernel version where the API/abi have drifted so far that the old module won't compile or import. If you can't afford to get your hands dirty and hack at the API changing if this has such a bus factor. DON'T USE IT. Frankly the argument you're making is the other side of stick with ext2 since it works. It's probably going to die soon and frankly unless there's a community to support it. (such as zfs, or ext4 in the kernel, or CEPH in hpc corporate spaces)