Timeouts of about 1 minute with new SSD BX500, HD led on, kernel > 4.14

@Winnie. Ok, i will also try your rules, since now i have still very rare timeouts. The system is now already running much better with kernel 5.10. I assume that you mean 60-ioschedulers.rules and not 60-ioscheduler.rules. Note that KDEneon, which runs without issues, uses discard in fstab!
I have another system (HP m8000) where for Manjaro XFCE fstab is also configured with discard for the Samsung SSD 860 EVO 250GB (/ and swap). Seems that this was default at installation time, some years ago.

timer and service info:

● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Tue 2021-07-20 19:38:02 CEST; 13min ago
Trigger: Mon 2021-07-26 01:14:03 CEST; 5 days left
Triggers: ● fstrim.service
Docs: man:fstrim

jul 20 19:38:02 gsm-man-kde systemd[1]: Started Discard unused blocks once a week.

○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
Active: inactive (dead)
TriggeredBy: ● fstrim.timer
Docs: man:fstrim(8)

Edit: Sorry to say, but your rules appear to be not good for the BX500: Frequently freezes with timeout. So bfq seems to be the best.

No need to apologize, but I never said to use one scheduler over another. I gave you an idea and some instructions on how to check the current scheduler and change it on your own (to see which one gives you the best results.)

On my system it is 60-ioscheduler.rules, and I never created it myself. Either it went by a different name in the past, or a recent update uses a new name?

That may or may not be the sole reason for the strange behaviors with your SSD. Remember, we’re talking two completely different distros. In theory, using “discards” in the fstab will create more stress for the drive and can slow things down. In your case, you might experience something different. Either way, it’s good to rule things out, so that if one method solves your problem you can safely omit discards from your fstab (since it’s not needed, and could possibly create issues down the line.) The weekly timer will handle routine trimming, which in turn is used by the SSD’s internal garbage collection.

You are right and it was a very good suggestion. So either discard in fstab or bfq shows the best results for my BX500, with only very incidently a sort freeze. I am also testing if removing gvfs has some effect.
I think that discard was default in older Manjaro releases. For test purpose only, i removed discard from fstab in KDE neon and that did not make any difference. With KDE neon the trim timer is running.

Thank you very much for your very useful ideas and quick reactions.

1 Like

Actually after removing discard from fstab Manjaro Linux KDE works better today. However stll some freezing incidentally. Now testing with mq-deadline.

Final conclusion for the time being:
The io-scheduler rules settings below work the best, with discard removed from fstab. Very few delays however still happen .
Manjaro is the fastest (startup time) system, in comparison with ArcoLinux, Kubuntu and KDE neon, but it is harder to install Manjaro on the BX500. That is because of the many timeouts (HDD LED on), which do not occur in this way and so often during the installation of the other distributions.
I consider this topic solved.

ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq-sq"

I’m just marking this topic as solved for you based on the above.

Seems that firmware F8F (Beta!) for the GA-MA770-DS3 (Rev 1.0) may have solved the biggest SATA timeout problem with newer kernels. Still testing. In the end F8F unfortunately is not a solution.
Edit: The BX500 works fine without any error in a HP Pavilion PC m8000. There must be something wrong with the Gigabyte GA-MA770-DS3 (rev 1.0) board.


This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.