Announcement

Collapse
No announcement yet.

Bcachefs Submits Lots Of Fixes For "Extreme Filesystem Damage" With Linux 6.9

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by User42 View Post

    Well, no... I can claim I'm Santa Claus. If I want to be taken seriously, I need to provide proofs. Telling others they need to prove I'm not just doesn't work: they don't need to prove anything. They don't believe me and I gave them nothing so I'm just going to be ignored. Did you believe people would trust you by default? You're not in that position.

    Plus, and that tells a lot, the situation here is worse because one cannot prove absence.
    ok Santa

    Comment


    • #62
      Originally posted by LinAdmin View Post

      IMHO the statements abaout BtrFS are fully correct and about ZFS they look probable.
      Well, that is up to you. It is your opinion based on your perception of what you believe is facts.

      What I hope we CAN agree on is that BTRFS has not been very good at pointing out which features are ready and which features are not.
      I myself nagged the BTRFS dev's about a status page similar to the Noveau's feature matrix and behold, it finally happened albeit it is close to 8 years old.
      The quality of the status page has been fairly good over the years , and give a good idea about what features are "safe" and what features are not.

      And yes, I have a interest in BTRFS and have used it for almost everything including lots and large with bursts of relatively heavy load without any issues at all. And while I admit to being a BTRFS "evangelist" I am not really religious either so I have nothing against BcacheFS or it's 'disciples'.

      What I really hope is that BcacheFS does not copy the mistakes of BTRFS e.g. 1. being merged a bit too early, and 2. does not inform it's userbase about what features are considered stable or not.

      http://www.dirtcellar.net

      Comment


      • #63
        While I agree with the lack of transparency (and generally a certain approach to bug fixing that has, sometimes, been appallingly dumb), an important nugget of a fact is that Btrfs lost its experimental status only "fairly recently"...

        For years after its introduction (in 2009), mkfs.btrfs would try to scare you off with how experimental the thing was. The wiki still warned you it was experimental until after Oracle adopted it and actually released it in their products. That should be around 2014.

        ​​After that, btrfs still had 4 main problems... 1. It had no online fsck tool to recover the data (like bcachefs has just released!); 2. There was that raid56 problem they took time to identify and document; 3. they got badly hurt by lying hardware (that's what you get for checksumming everything); 4. their existing fsck tool had appalling UX (yeah, it WARNED the users pretty loudly they needed to contact the devs for recovery instruction, but users just disregarded the thing and destroyed their data in the process and who would blame them ffs, if you need low levels tools don't release them in the same binary as UNIMPLEMENTED recover options while giving them recovery-related names!).

        Out of all these, I'm not sure fsck got so good it can pull what Kent has described for bcachefs ("as long as the inodes blahblah, everything can be reconstructed") but the issue with raid is now documented and finally being worked on and the rest was basically solved 10 years ago... when Btrfs lost its experimental status.

        Again, the road was bumpy and the approach to bug squashing was sometimes "very shortsighted". I have no doubt most of the same people who got burned by Btrfs between 2009 and 2014 will be burned by Bcachefs (though the hardware situation got better).

        As for the tongue-in-cheek "not eating your data", failing HW will eat your data whatever happens so you need backups if these data are important. Sure, being able to recover data is super duper neat, I'll choose that any day over having to restore a backup... But being "technical" about bcachefs being borked "but it's ok because your data is still there, on disk" is a bit ludicrous... Especially when the phrase was coined referring to Btrfs... Especially when Btrfs has not eaten data since it lost its experimental warnings (in stable modes)... At this stage Bcachefs is no better than Btrfs and it will need a bit of time to achieve that (unless it gets a few unforeseen warts of its own that prevents that).

        I really wish all the best to Bcachefs but I already know it's going to be bumpy... I also really hope (as a potential future user, actually excited by Bcachefs) that they'll bring more on the table than a "more stable Btrfs" because becoming more stable will still take a few years of bumps, compared to a FS that has already matured... It's not going to be easy, in many ways.

        ​​​​​

        Comment

        Working...
        X