Announcement

Collapse
No announcement yet.

Fedora Looking At Finally Enabling FSTRIM By Default In Fedora 32

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

  • #11
    TRIM is only fast when it's queued and some drives had bugs with that so I believe Linux disabled all queued TRIM. It might still be allowed on NVMe.

    Comment


    • #12
      Just enabled it on RHEL 8, the timer (and service) are off by default. Huh, never would have thought of that before seeing this.

      Cheers,
      Mike

      Comment


      • #13
        Originally posted by Britoid View Post
        Running TRIM commands after each delete slows down the system.
        As otherwise mentioned, depends on whether the discard (trim for sata, unmap for scsi) is issued synchronously (which it does for some file systems), and the SSD itself (and how it handles the operation internally). For that matter, for some enterprise drives manage free space in ways such that discard may not substantially improve performance.

        Defaulting (but allowing user overrides) to a weekly fstrim is considered the current best practice consensus for consumer based systems. Enterprises know (or should know) exactly how their storage operates, and should have their system configuration deployments (using ansible or equivalent) set exactly what they need (whether that is a weekly fstrim or block by block discard or nothing at all).

        Comment


        • #14
          Originally posted by willmore View Post
          Why only fstrim weekly instead of TRIM enabled in filesystem and LVM? Isn't that better for the SSD?
          Discarding (TRIM'ing) deleted blocks in real-time is theoretically better for longevity, but carries a (sometimes very large) performance impact, at least for SATA SSDs, unless the SSD supports queued TRIM.

          Comment


          • #15
            Originally posted by CommunityMember View Post

            As otherwise mentioned, depends on whether the discard (trim for sata, unmap for scsi) is issued synchronously (which it does for some file systems), and the SSD itself (and how it handles the operation internally). For that matter, for some enterprise drives manage free space in ways such that discard may not substantially improve performance.

            Defaulting (but allowing user overrides) to a weekly fstrim is considered the current best practice consensus for consumer based systems. Enterprises know (or should know) exactly how their storage operates, and should have their system configuration deployments (using ansible or equivalent) set exactly what they need (whether that is a weekly fstrim or block by block discard or nothing at all).
            Windows has an internal list of SSDs to not enable trim for, I wonder if it's possible to do the same on Linux, although it surely would have to be a kernel thing.

            Comment


            • #16
              Originally posted by Britoid View Post

              Windows has an internal list of SSDs to not enable trim for, I wonder if it's possible to do the same on Linux, although it surely would have to be a kernel thing.
              There are ATA quirks. But they work as an additional blacklist. It's still on userspace to even attempt to enable/utilize discard/TRIM in the first place.

              Comment


              • #17
                Originally posted by Britoid View Post

                Running TRIM commands after each delete slows down the system. Imho the kernel should be passing trim occasionally when there's little activity.
                Yes, if the drive doesn't supported queued TRIM commands, then you can block on them in the command stream. If the driver is to hold them back until the drive is idle, it'll need to track pending TRIMs against all writes. You don't want to turn a TRIM <block_a> WRITE <block_a> into a WRITE <block_a> TRIM <block_a> by accident.

                It just strikes me that weekly is way too infrequent. Maybe daily would make more sense. It's not like TRIM causes wear on the drive. The only downside is occupying the drive for a while. But if it's at an idle time, it should have little impact.

                Comment

                Working...
                X