Is Linux so “fragile”? A strange experience with USB hubs
I don’t know whom to blame for what I experienced, so I’ll just describe the facts.
My HP ProDesk 400 G6 mini-PC, in the 44G38ES configuration (upgraded with a second SSD) is still running AlmaLinux 9.4 KDE, despite my recent reconversion to Ubuntu MATE. If it works, it works.
At the same time, I needed to refresh my backups that include 18 external HDDs and a limited number of SSDs. To this purpose, I made use of whatever hardware was available, including my wife’s HP Pavilion TG01 running Win10 22H2, and a Win7 machine. Since HDDs are quite slow, using a good USB hub shouldn’t hurt, and we each own one of the following USB 3.2 Gen 2 hubs by Inateck: mine is the one that works on USB-A, my wife’s is the one ending in USB-C:
So far, so good. Let me summarize the experiences had with these USB hubs.
💾 With HDDs:
- Win10: 🟢 no problems whatsoever.
- Win7: 🟢 no problems whatsoever.
- Linux: 🟢 no problems whatsoever.
💾 With SSDs:
- Win10: 🟢 no problems whatsoever.
- Win7: 🟢 no problems whatsoever.
- Linux: 🔴 big problems!
I should elaborate on what happened under Linux. I only experienced the issues I’ll describe under my AlmaLinux 9.4 KDE that uses kernel-lt
from ELRepo (currently 6.1.112), because the official 5.14 is so fucking old. The HP mini-PC works great, except that the following things happened.
Let the horror begin!
■ With KDE configured to automatically mount all external drives, I inserted the USB hub while 4 SSDs were already connected to it. ➡️ The entire KDE session crashed, and X11 with it!
■ I then inserted the hub alone, and started inserting SSDs one by one. ➡️ If I inserted them too quickly one after another, the system wouldn’t see them all, but only 2 or 3 out of 4!
■ With all 4 external SSDs connected via the hub and mounted, I inserted a USB flash drive in another USB connector. ➡️ Two of the four mounted SSD were suddenly unmounted!
■ With all 4 external SSDs connected via the hub and mounted, I started copying and moving files around. ➡️ During the file transfers, 1-2 of the mounted SSD were abruptly unmounted mid-transfer!
■ Despite the external devices being exFAT, the following behavior wasn’t really to be expected. When the destination SSD become unmounted, this is what I was left with:
- Some files were correctly moved to the 2nd SSD.
- Some other files were created with a size of zero on the 2nd SSD, yet the originals were deleted from the source SSD!
- A last set of files were nowhere to be found: they were not created on the 2nd SSD, but they have been deleted from the source SSD nonetheless!
Now, I’m aware that there are several stupid factors by design in all the modern OS, such as:
- A cache at the OS level, so Dolphin or whatever process initiates the copy cannot know for sure whether the files have indeed been written to the destination.
- A cache at the destination device (HDD, SSD, whatever has a controller).
Still, some elementary logic should apply:
- Those files with null size should have been written by the SSD if the contents reached it, because the SSD was still powered. Even if logically unmounted, it was still connected and powered! The facts suggest that the contents never reached the SSD’s controller! So how could Linux give the command “create this bunch of files, and I’ll give you their contents later,” and at the same time make Dolphin believe that the files were successfully copied, so that Dolphin deleted the originals?!
- The case of the files that were “lost in Nirvana” is even worse. They were lost in Linux’s cache when the SSD was forcefully and dumbly unmounted, and yet Dolphin still believed they were copied, so it deleted the originals!
This is 200% incomprehensible and unacceptable.
If a modern OS disconnects so severely a process from what’s actually happening, what’s the fucking purpose of this shit?! To MAXIMIZE the loss of data?
Even in MS-DOS and Win3.1 this wouldn’t have happened. Using xcopy /v
was only necessary if we wanted to make sure that what was written can be read back and has the same checksum, but when surface defects weren’t suspected, any simple copy
or move
command would have known when a file was indeed written! In my entire life, I never experienced a move operation that deleted the source files when the destination ones weren’t created and written into!
And now we even have journaling in this brave new world. Not in exFAT nor in FAT32, but how could have journaling improved the situation, when the initiator of the copy, Dolphin, doesn’t fucking know if the files have even reached the destination?
How stupid do you want your Linux to be today?™
The issue should have been the instability of Linux when a certain USB hub is connected to it, but instead I discovered one more stupidity by design. Really, is Linux developed by the most retarded people on Earth?
Yes, I was happier with MS-DOS and Win3.1, and I kid you not.
Oh, that USB hub is seen as: 2109:0822 VIA Labs, Inc. USB3.1 Hub, which is this VL822 controller.
Great. But is this a problem with Linux as a whole or with Alma or KDE or Dolphin ?
That’s a great question.
It happened to me too!!! I was completely in disbelief and thought it must have been due to my inexperience with Linux. If someone cut-and-paste… nothing should be deleted unless it is pasted right! No cached or anything else, only successfully copied before deleting anything!
What is obvious to common logic isn’t necessarily obvious to the retarded software developers.