Announcement

Collapse
No announcement yet.

Linux 6.2 Likely To Enable Btrfs Async Discard By Default

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

  • Linux 6.2 Likely To Enable Btrfs Async Discard By Default

    Phoronix: Linux 6.2 Likely To Enable Btrfs Async Discard By Default

    Btrfs' async discard functionality will likely be turned on by default with the upcoming Linux 6.2 kernel cycle when running on an SSD...

    https://www.phoronix.com/news/Btrfs-...iscard-Default

  • #2
    BTRFS is a great and robust filesystem and I am an "enthusiast" and supported of it , but enabling async discard is something I fear will cause additional corruption (on bad hardware) and contribute to giving BTRFS a bad reputation (again). You never know , but I fear this change will be reverted shortly due to issues with "funny" firmware implementations. Hope I am wrong though

    http://www.dirtcellar.net

    Comment


    • #3
      Originally posted by waxhead View Post
      BTRFS is a great and robust filesystem and I am an "enthusiast" and supported of it , but enabling async discard is something I fear will cause additional corruption (on bad hardware) and contribute to giving BTRFS a bad reputation (again). You never know , but I fear this change will be reverted shortly due to issues with "funny" firmware implementations. Hope I am wrong though
      why would it "cause additional corruption"?
      no btrfs developer raised such a concern when the topic was discussed on the mailing list.

      am I missing something?

      Comment


      • #4
        This does not change whether discard is done or not. It just changes, when the discard is done. It would be highly surprising if broken firmware in general could cope better with one way of doing this than the other.

        Comment


        • #5
          So wait a second. I was under the impression that it was better to use a scheduled fstrim rather than the discard option. The recommendation now is to use discard=async instead? The Btrfs FAQ page does not yet even mention that option:
          https://btrfs.wiki.kernel.org/index....M.2Fdiscard.3F

          Comment


          • #6
            Is there a true reason to use this on a desktop instead of ext4 these days? Genuine question, i am going to upgrade my hard drive in the near future and i am pondering if i should use it or not. Is it any faster, more reliable, etc for ONLY desktop use cases? Not doing any server stuff on my desktop.

            Comment


            • #7
              Originally posted by TemplarGR View Post
              Is there a true reason to use this on a desktop instead of ext4 these days? Genuine question, i am going to upgrade my hard drive in the near future and i am pondering if i should use it or not. Is it any faster, more reliable, etc for ONLY desktop use cases? Not doing any server stuff on my desktop.
              personally I love btrfs because I use (and probably abuse...) snapshots.
              they saved my life so many times that I'm afraid to do everything when I'm working on a machine without snapshots!

              other things that I like:

              * it makes my backup easier.
              * it detects bitrot so I can detect and recover corrupted files.

              It's not the fastest fs when working with spinning rust and VMs, but the features are worth the compromise in my case.

              for the stability, I've been using it since before it was officially merged in the kernel and I'm not having issues since ages, despite its bad reputation.

              Comment


              • #8
                Originally posted by Chugworth View Post
                So wait a second. I was under the impression that it was better to use a scheduled fstrim rather than the discard option. The recommendation now is to use discard=async instead? The Btrfs FAQ page does not yet even mention that option:
                https://btrfs.wiki.kernel.org/index....M.2Fdiscard.3F
                +1 to that question. I use systemd fstrim scheduled service. Why I would now discard blocks in real time, if for years it has been recommended to do scheduled fstrim?

                Comment


                • #9
                  Originally posted by cynic View Post

                  personally I love btrfs because I use (and probably abuse...) snapshots.
                  they saved my life so many times that I'm afraid to do everything when I'm working on a machine without snapshots!

                  other things that I like:

                  * it makes my backup easier.
                  * it detects bitrot so I can detect and recover corrupted files.

                  It's not the fastest fs when working with spinning rust and VMs, but the features are worth the compromise in my case.

                  for the stability, I've been using it since before it was officially merged in the kernel and I'm not having issues since ages, despite its bad reputation.
                  Yeah, at this point I would be more nervous about storing data on Ext4 since it doesn't do any data integrity checks or snapshots. And of course Zstd data compression is another big advantage, as well as the ability to use send/receive for backups or data transfers. It doesn't make any sense to be afraid of Btrfs anymore. It has been running very reliably for years.

                  Comment


                  • #10
                    Originally posted by cynic View Post
                    It's not the fastest fs when working with spinning rust and VMs, but the features are worth the compromise in my case.
                    Targeted use of nodatacow can help there, for databases and the like that have their own data corruption checking (at least PostgreSQL does, if you have it turned on).

                    Spinning rust performance has also improved in some areas, for example scrubs got noticeably faster in recent backported kernels. Here's how it impacted my system (this disk is part of a four-disk RAID5 on which a full scrub is performed over the quietest hours of each day by repeated pausing and resuming in cron, to limit CPU usage - I had to reshuffle cron because it got done faster and so wasn't spread out over the whole week anymore).

                    sda-year.png

                    Comment

                    Working...
                    X