• LazerFX
    link
    fedilink
    English
    arrow-up
    4
    ·
    5 months ago

    That’s because the drive was written to its limits; the defrag runs a TRIM command that safely releases and resets empty sectors. Random reads and sequential reads /on clean drives that are regularly TRIMmed/ are within random variance of each other.

    Source: ran large scale data collection for a data centre when SSDs were relatively new to the company so focused a lot on it, plus lots of data from various sectors since.

    • Alawami@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      5 months ago

      I’m pretty sure running XFS defrag will defrag without trimming no matter the type of block device.

      Edit: yea you might actually be right. I Played with my fstab too much years ago, and never thought of that untill now

      • LazerFX
        link
        fedilink
        English
        arrow-up
        2
        ·
        5 months ago

        I understood that XFS automatically mounted SSD’s with XFS_XFLAG_NODEFRAG set? Is this not the case?

        • Alawami@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          5 months ago

          yea you might actually be right. I Played with my fstab too much years ago, and never thought of that until now

          But does that flag affect manually running xfs_fsr?

          • LazerFX
            link
            fedilink
            English
            arrow-up
            2
            ·
            5 months ago

            According to the man(8) page, it will avoid touching any blocks that have the chattr -f flag set, which is XSR_XFLAGS_NODEFRAG… So I think if the docs are still accurate to the code, yes.

            A lot of ifs in that assumption.