0

Again, the / and /home and all the software and cache and data folders are on SSD.

Everything just freezes with periodic (seconds to minutes!) updates: bar stop updating (custom eww one + shell scripts for status info (including mpd track which is on HDD, see below)), hotkeys stop working (keyd + my own custom socket shenanigans), applications lag and freeze, even zsh won't load, from ssh or in a terminal emulator (vanilla zsh with a couple of manually installed plugins like autosuggestions & highlighting & autopairs), though clean bash shells and my Hyprland itself continued to work fine and responsive (it's own key binds like workspace switch & window navigation work fine). The same was also true back when i was on an X11 WM.

Not only it happens under benchmarks but also in real usage like while torrenting large files to that disk, though less so but still extremely annoying anyway as my bar lags.

I've just ran a KDiskMark benchmark on that HDD and it was like 1.5 hours of unusable system (and that with me stopping it on 1/5 random writes). (speeds are fine though at 137/32 and 0.48/0.39 seq/rand read/write, seems inline with HD tests that i've seen online).

The same benchmark on the system SATA SSD produces far less lag and actually completes not in hours.

I don't think my system runtime depends on that hard drive at all but maybe mpd music folder which is on that HD (and was paused during the test). Besides media and some light games that are on it, the only interaction with it that can happen is my bind mounts at /var/lib/{cabal,cargo,stack}, /srv/media and /srv/steam and a soft link at ~/mus/media_container, which are obviously touched only when using the corresponding software or playing media (which i was not).

Can anybody explain to me what's happening? Has anybody ever encountered anything like that? I can't google it because it's only people who are having slow system on HDs there, but maybe i just can't google.

Is it NTFS? Is it ntfs-3g userspace driver specifically? But why it affects the whole system, if so? Is it hardware failure and Linux freaking out because of it (unlikely, the drive is old but this issue is also old and i think it would've been dead or corrupted long ago then)? Is it my shell scripts that power the hotkeys&bar which are too clunky or something (no way that a couple of dash&grep&ncat processes would be THAT bad and then again, the lag only happens on HD load to which the scripts have no connection)?

The only thing except the above that i can think of... Can the motherboard chipset or whatever-something of it be the bottleneck? It's quite old 2009/2010 MS-7616. The thing is that the SSD which is on the neighboring SATA port works fine as i've said.

Some other info:

  • CPU usage did not exceed 30% (so maybe 1/4 cores)
  • RAM usage did not exceed 4G/8G
  • I don't use swap on disk, only zram swap which i've disabled halfway into the benchmark
  • I've started the benchmark with Firefox & other software running but ended up killing all of that just in case
  • Random writes tests took the most time.
  • SATA cables seem fine and in place.
  • sudo htop showed no process having much IO usage in IO tab (?) while the benchmark was running and system was half-frozen
  • The lags did not stop after i pressed "Stop" in KDiskMark for another like ~10 minutes (including KDiskMark itself not doing anything except presenting me an edit line with the drive model in it at the bottom for some reason, until the end when it returned to the launch/idle state), but that may be it just running the ongoing random write pass to the end.

Edit: The issue still (kind of) seem to hold even on another (more modern/performant) system with the same HDD and same NTFS filesystem. Although KDiskMark now does nothing to the overall responsiveness, this time i got caught by grep left forgotten in a terminal, which followed a symlink to that NTFS filesystem and was scanning all my files. The performance did not plummet like on the first system but decreased noticeably.

I still want to know why and how it's happening.

4
  • 1
    Native NTFS3 works well, you could give it a try. Commented Jun 25 at 8:00
  • @ArtemS.Tashkinov not sure about it, when it first came out it was not ready (bugs, instabilities or something & lack of maintenance after the initial release) and i can't really afford to lose that data (that's what i'm in the process doing now btw - migrating that data away from the NTFS partitions, but if ntfs-3g is the problem i still want to know how it can tank the whole system). Checked on it some time ago, maybe half a year and it still was this way and still not used by distros such as Debian - though, i'm aware that it's now the default and the only NTFS driver in the kernel.
    – hertonth
    Commented Jun 25 at 12:55
  • I couldn't care less about Debian. I'm now running 6.9.6 and feeling fine. Lastly if you're concerned about data safety I've lost data to NTFS-3G on multiple occasions during normal operation. It's never been safe either. If you wanna be near 100% safe, you fire up a Virtual Machine, give it these partitions and then share them via CIFS aka Windows File Sharing. Under Linux you don't even have chkdsk. You cannot be sure your partitions are not without major errors at the moment. Or you could move this drive into a separate PC with Windows installed. Commented Jun 25 at 14:00
  • Did you ever bother to check dmesg output? If the problem persists between different systems it may be hardware (the disk/its controller) rather than the file-system or drivers in use.
    – tink
    Commented Jul 4 at 18:00

0

You must log in to answer this question.

Browse other questions tagged .