Announcement

Collapse
No announcement yet.

OpenZFS Native Encryption Use Raises Data Corruption Concerns

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

  • OpenZFS Native Encryption Use Raises Data Corruption Concerns

    Phoronix: OpenZFS Native Encryption Use Raises Data Corruption Concerns

    At the end of last year OpenZFS 2.2.2 was released to fix a rare but nasty data corruption issue but it turns out there are other data corruption bug(s) still lurking in the OpenZFS file-system codebase...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Of course there are ZFS data corruption bugs. Only silly fanboys think any major complex filesystem is perfect.

    Comment


    • #3
      We need a file system written in Rust so we can use mutex, message passing and immutable data types to achieve a safe file system without race conditions, memory allocation bugs, and other problems.

      Comment


      • #4
        Originally posted by uid313 View Post
        We need a file system written in Rust so we can use mutex, message passing and immutable data types to achieve a safe file system without race conditions, memory allocation bugs, and other problems.
        That's the direction bcachefs appears to be heading

        Comment


        • #5
          This looks like it's making news out of the biased opinion of one random bug poster that didn't actually experience such a bug themselves. I've been using ZFS native encryption with send/receive on my own data nearly since the time that native encryption was released, and it has been working perfectly for me.

          Comment


          • #6
            Originally posted by fong38 View Post

            That's the direction bcachefs appears to be heading
            It's too early to guess, but I wish bcachefs wuld be simple, not feature bloated to keep it less buggy. Just cow fs with basic raid configs like mirror/raid6 and recovery tools to deal with it. Of corse I really like block level dedup and snapshots, but all great things ZFS can do keep it so complex and hard to maintain bug-free.

            Comment


            • #7
              I don't get one thing, if a future is broken/not recommend by the maintainer them self why it is enabled in production builds?
              Or at least put it behind a special experimental flag. Same goes for btfs and it broken raid 5

              Comment


              • #8
                I've never had any issues with ZFS ever on any OS using it. My ArchLinux rig uses ZFS for root and it's my daily driver.

                Encryption... Oh lord. How many home users actually need to have an encrypted file system at all? Answer few if any, possibly none. Encryption is for datacenters, government officials, and businesses needing workstation, server, and laptop security. For average Joe user at home, you're wasting you time setting up something you'll never benefit from.

                OpenZFS is fine as is as long as you use it normally like a normal sensible person. In fact it's probably a filesystem that honestly, you set it up, and barely do anything afterwards unless you're updating a zpool to a new version, scrubbing the zpool for maintenance, or maybe create a new mountpoint for to add a new drive to the system. I would actually say it's the equivalent of a Ron Propeil "Set it and Forget it filesystem". If you're going out of your way to play IT professional at home, then YMMV as to what can and could happen.

                Any filesystem can have data corruption, data loss, and data problems. The problem isn't the file system. The problem is the user that causes the problem by doing things that are unnecessary for their use case.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  We need a file system written in Rust so we can use mutex, message passing and immutable data types to achieve a safe file system without race conditions, memory allocation bugs, and other problems.
                  With some sarcasm, you won the buzzword bingo contest with that request :-) All kidding aside, I get your intent, and I am 100% on board. A filesystem needs to be 100% all the time with no room for error. Personally if I could just get eithe EXT4 or XFS with check-summing capabilities, I would be good quite happy.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    We need a file system written in Rust so we can use mutex, message passing and immutable data types to achieve a safe file system without race conditions, memory allocation bugs, and other problems.
                    These are all lovely things to say, but brutally hard to implement while keeping performance above the movement of a glacier!

                    Comment

                    Working...
                    X