Announcement

Collapse
No announcement yet.

OpenZFS 2.2.1 Released Due To A Block Cloning Bug Causing Data Corruption

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

  • #31
    Originally posted by avis View Post
    There's just one truly robust fs under Linux and that's ext4|3|2. Everything else is for those who loves to play with fire.
    Not entirely true. XFS has much better performance and much better tested(it's used in enterprise).
    Ext4 has case-folding and encryption, but those features were ridden by bugs in the past.

    Comment


    • #32
      Originally posted by avis View Post
      I've not lost a single file to fat32/ntfs/ext{2|3|4}, the only FS'es that I trust.
      that's not in contrast to what I wrote.

      anyway, if you have a large amount of data stored somewhere (like, I guess, all of us) is very likely that you actually have corrupted data somewhere.
      you just cannot detect it due to the lack of checksumming and a scrub function.

      Comment


      • #33
        I feel like a lot of BTRFS people are being so harsh on ZFS right now because a lot of ZFS people constantly attack BTRFS over every little (sometimes insignificant) thing. It’s amazing how “all software has bugs” only when it’s ZFS being criticized.

        Comment


        • #34
          Originally posted by evil_core View Post

          Not entirely true. XFS has much better performance and much better tested(it's used in enterprise).
          Ext4 has case-folding and encryption, but those features were ridden by bugs in the past.
          ext4: 2 billion users.
          XFS: < 200K users.

          And I lost ~200GB of data to XFS albeit around 2005 when it probably wasn't worth using.

          Comment


          • #35
            Originally posted by EphemeralEft View Post
            I feel like a lot of BTRFS people are being so harsh on ZFS right now because a lot of ZFS people constantly attack BTRFS over every little (sometimes insignificant) thing. It’s amazing how “all software has bugs” only when it’s ZFS being criticized.
            I'm not wasting my harshness with ZFS: I prefer btrfs but at the end of the day both fs are good.
            I'm keeping it all for when we'll start hearing about "The COW filesystem for Linux that won't eat your data"


            Comment


            • #36
              Originally posted by JanW View Post

              Fallacy of composition: Just because you (one member of the population) never lost any data using Btrfs does not mean no one in that population has. You seem to conclude from your own experience with Btrfs that there are fewer data losses with Btrfs than OpenZFS in a given population of users.


              You didn't understand anything of what I wrote, I didn't conclude anything, I use btrfs because I use some features that ext4 doesn't have, I never wrote that data loss will never happen with btrfs, that's just my experience.
              I was only contesting the urban legend about the unreliability of btrfs, by the way the last time I had data corruption was with the super stable ext4.
              The moral of it all is that it can happen with any fs, but stop saying that btrfs is unreliable.​

              Comment


              • #37
                Really glad to see this, and especially to see that it isn't a completely new issue. I've been running into this issue for months and my investigation found zeroes in chunks of files that were new files that I had just checksummed, but I hadn't been able to find anyone talking about it.

                Comment


                • #38
                  Originally posted by EphemeralEft View Post
                  I feel like a lot of BTRFS people are being so harsh on ZFS right now because a lot of ZFS people constantly attack BTRFS over every little (sometimes insignificant) thing. It’s amazing how “all software has bugs” only when it’s ZFS being criticized.
                  imo, the harshness for BTRFS is entirely justified.

                  It's being used as the default in multiple distros simply because it was (until recently) the only in-tree CoW filesystem, yet every single week there are fresh tales of people loosing data to it. It's gone on so long that people loosing data to BTRFS has become a constant background noise that everyone has gotten used to. Descriptions of people's experiences of BTRFS are always tempered with "I've never personally lost data" with the implied caveat being that they've heard of people who have.

                  This might be the first data-eating ZFS bug to reach production in over a decade and it was found and fixed immediately after release. It's also very notable that this development cycle involved heavy modification of the block cloning subsystem (likely to support current and upcoming reflink and fast-dedup work) where this bug was found, meaning that this bug was likely born in the last few weeks. How many years have most bugs lingered in BTRFS, eating people's data, before finally being resolved?

                  The difference in reliability between the two filesystems is nothing short of staggering. If people want to stop BTRFS getting criticised, they should stop using it. It's been rancid since it's inception.

                  Comment


                  • #39
                    Originally posted by Developer12 View Post

                    imo, the harshness for BTRFS is entirely justified.

                    It's being used as the default in multiple distros simply because it was (until recently) the only in-tree CoW filesystem, yet every single week there are fresh tales of people loosing data to it. It's gone on so long that people loosing data to BTRFS has become a constant background noise that everyone has gotten used to. Descriptions of people's experiences of BTRFS are always tempered with "I've never personally lost data" with the implied caveat being that they've heard of people who have.

                    This might be the first data-eating ZFS bug to reach production in over a decade and it was found and fixed immediately after release. It's also very notable that this development cycle involved heavy modification of the block cloning subsystem (likely to support current and upcoming reflink and fast-dedup work) where this bug was found, meaning that this bug was likely born in the last few weeks. How many years have most bugs lingered in BTRFS, eating people's data, before finally being resolved?

                    The difference in reliability between the two filesystems is nothing short of staggering. If people want to stop BTRFS getting criticised, they should stop using it. It's been rancid since it's inception.
                    If you read the comments on the bug report and the pull request that looks like it fixes it, you'd see that developer thinking that the issue has been in the ZFS codebase since at least 2013. The issue has only been exacerbated recently because of the update to coreutils changing the default behavior of cp. I've personally been dealing with this since before updating to 2.2.0 in Ubuntu 23.10 without block cloning enabled. The fix in 2.2.1 reduces the incidence of data corruption, but doesn't eliminate it. This doesn't reduce my trust of ZFS because it was only corrupting new files with holes, not putting regular old files at risk.

                    Comment


                    • #40
                      Originally posted by BwackNinja View Post
                      found zeroes in chunks of files that were new files that I had just checksummed, but I hadn't been able to find anyone talking about it.
                      Maybe this:

                      PSA: it's not block cloning, it's a data corruption bug on reads in ZFS 2.1.4+, set zfs_dmu_offset_next_sync=0 : zfs

                      Comment

                      Working...
                      X