5 ms·

This can happen with primadonna devs who haven't had to collaborate in a team environment for a long time. It's a damn shame too because bcachefs has some uniq

This can happen with primadonna devs who haven't had to collaborate in a team environment for a long time. It's a damn shame too because bcachefs has some unique features/potential

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
    > 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)

This can happen with primadonna devs who haven't had to collaborate in a team environment for a long time. It's a damn shame too because bcachefs has some unique features/potential

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
  > 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)