Announcement

Collapse
No announcement yet.

temporary hang, then "fstrim: backing device does not support discard"

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

    temporary hang, then "fstrim: backing device does not support discard"

    I've been getting occasional lockups of my system -- the mouse freezes, and maybe 10 seconds later everything comes back normal. In the journal this correlates with three lines like this:
    Code:
    Jan 13 10:15:22 mymachine ntfs-3g[1746]: fstrim: backing device does not support discard (discard_max_bytes == 0)
    ...these seem to correlate with three partitions on a drive I have installed. It's not an SSD, rather a 3TB HDD. Using lsblk -D I can confirm that "DISC-MAX" is 0B for all of those partitions, which makes sense since it's an HDD.

    I'm not sure if the hang/freeze is due to these errors, or just happens every time the fstrim service is triggered, but I'm wondering why the fstrim service would even be running for an HDD?

    These partitions are mounted via ntfs-3g (ntfs3 seemed to be causing corruption), like so:
    Code:
    UUID=1234567890ABCDEFGH /mypartition          ntfs-3g    defaults,umask=007,gid=46,uid=1000 0       0
    Any ideas are appreciated, thanks!

    #2
    Instead of the line from your fstab, post the output of the "mount" command regarding that file system. I will reveal the existing mount options. We have trim service that runs periodically so mounting with discard as an option is not necessary.

    Please Read Me

    Comment


      #3
      Thanks, oshunluvr --

      Code:
      /dev/sde1 on /part1 type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
      /dev/sde2 on /part2 type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
      /dev/sde3 on /part3 type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)​

      Comment


        #4
        All my searching shows is this has been an issue off and on for many years. Being that NTFS is not a linux file system and you have to rely on ntfs-3g - a type of "fuse" file system - this may just be a bug regression. You should probably just turn off discard for your ntfs file systems and not worry about it.

        You also mention "ntfs causing corruption" but I don't understand what you mean by that.

        trim runs on a systemd timer and I can't see a way to disable it on a per-file system basis. You should probably just turn off the service and run fstrim on spefici devices in a weekly cron job.

        Please Read Me

        Comment


          #5
          Thanks! Any tips on how to disable discard for specific filesystems? I couldn't easily find much from google (or man pages), but I did see one mention of "nodiscard" as a mount option... I added that to fstab:

          Code:
          UUID=ABCDEFG12345678 /part1            ntfs-3g    defaults,nodiscard,umask=007,gid=46,uid=1000 0       0
          ...did systemctl daemon-reload, and then remounted. It seemed fine, but "mount | grep sde" doesn't show anything about the discard option (not sure if it should?):

          Code:
          /dev/sde1 on /part1 type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
          I'll run with that for a while and see how it goes.

          You also mention "ntfs causing corruption" but I don't understand what you mean by that.
          I was getting corruption in my file systems: things like copying a file from one place to another with no error, but the file isn't in the destination, corruption errors in the journal, etc. Googling lead to a number of people saying that the newer ntfs3 may be to blame (here, here, here, here) so I downgraded back to ntfs-3g and it's been good since then.

          Comment


            #6
            I'll run with that for a while and see how it goes.
            ...didn't help, just happened again. At least it isn't common. But it would be a real bummer if it happened during something critical... so, attempt #2, based on a chatbot response and some googling:

            make /etc/systemd/system/fstrim.service.d/ignore-ntfs-hdd.conf:
            Code:
            [Service]
            # Clear the original ExecStart setting
            # original is in /usr/lib/systemd/system/fstrim.service
            ExecStart=
            # Filter out the NTFS mount from mountinfo and then run fstrim on the rest
            ExecStart=/bin/sh -c "grep -v sde[1-3] /proc/self/mountinfo | fstrim --listed-in - --verbose --quiet-unsupported"
            Then:
            Code:
            # systemctl daemon-reload
            # systemctl restart fstrim.timer
            There does exist an fstab option X-fstrim.notrim, but it's unclear to me if it would work with ntfs-3g, and since the default fstrim service calls fstrim with "--listed-in /etc/fstab:/proc/self/mountinfo", I guess it might pull the mount from /proc/self/mountinfo even though fstab tells it not to. Will see how this goes!

            EDIT re: --listed-in: "The evaluation of the list stops after first non-empty file.​" -- ah, so probably could just use that X-fstrim.notrim option if ntfs-3g supports it.
            Last edited by chconnor; Feb 18, 2025, 12:41 AM.

            Comment


              #7
              I do not believe you can disable the systemd trim service on a per file system basis. That's why I suggested disabling the systemd service and then either running trim manually or creating a crontab entry to run it on whichever file systems you wish. IMO the default of once a week is unnecessary, Once a month should be plenty unless you're moving GBs around on a daily basis.
              Last edited by oshunluvr; Feb 18, 2025, 07:43 AM.

              Please Read Me

              Comment


                #8
                Yeah, thanks, in the end I was basically doing as you suggested, just via the "drop-in" mechanism of systemd.

                But the X-fstrim.notrim does sound like a way to disable per filesystem, no? (from fstrim man page) Provided that a filesystem type supports it, I guess.

                Comment


                  #9
                  I hadn't heard of that. I wonder if "file system" means "all files systems of a specific format" or a single "file system" via mount point?

                  Please Read Me

                  Comment


                    #10
                    Aha!:
                    Code:
                      Filesystems with "X-fstrim.notrim" mount option in fstab are skipped.  ​
                    So it's per-mount point in fstab.

                    Please Read Me

                    Comment


                      #11
                      Originally posted by oshunluvr View Post
                      So it's per-mount point in fstab.
                      Yeah and I worried that because fstrim is (by default configuration in systemd) looking at both fstab and /proc/self/mountinfo it would trim all the mount points whether that option was used in fstab or not, but per the fstrim man page for the --listed-in option, "The evaluation of the list stops after first non-empty file", and fstab is first.

                      So I think the only remaining question is whether that option is actually used for all filesystem types; I heard that e.g. ntfs-3g may or may not "pass" that option somehow, so it's not clear to me if it always works, but at least for linux-y filesystems it seems like an option.

                      Comment


                        #12
                        Arch, as always, provides: https://man.archlinux.org/man/ntfs-3g.8#OPTIONS

                        It doesn't explicitly list notrim but that doesn't mean it won't work. It's worth a try IMO.

                        Please Read Me

                        Comment


                          #13
                          Looks like it's not recognized by code: https://github.com/tuxera/ntfs-3g/bl...g_common.c#L82
                          ...probably means it won't work? Or is there another mechanism by which it might get through?

                          Comment


                            #14
                            I believe that some mount options are FS dependent and some are not. If it were me, I'd put it in fstab. Then unmount it and remount it in the terminal and see if you get an error message. If not, let it ride and see if the hang reappears or not.

                            Please Read Me

                            Comment


                              #15
                              Ok -- I added it there as well (no error on re-mount), and I'll disable my fstrim.service.d fix and see how it goes.

                              Comment

                              Working...
                              X