Using an SD card for storage in GNU/Linux is broken

I have this annoying and persistent problem with my SD card for my netbook.

Basically, a while back, being a poor student and all, i got a pretty cheap netbook by a Polish company that was made in China. Now, it fits my expectations of a light device that i can lug around pretty well, and even has a backlit keyboard!

Some background on the hardware we're dealing with here

And then there's the problems. The Wi-Fi drivers didn't work out of the box (super annoying because of no ethernet port), and after manually compiling and installing them manually from some random GitHub repo (yay, security), they sort of started working, at least 60% of the time, even with pretty poor signal strength.

And the touchpad works in like half of the Linux distros that i tried, Fedora for example leaving you stranded only with the keyboard by default. The fingerprint scanner not only doesn't work, but also doesn't get detected. Of course, it might work in Windows, but with only 4 GB of RAM, that OS really isn't an option.

But it's a software problem

But the worst problem is the SD card, and perhaps not because of the actual hardware, but because of the OS. Linux Mint was chosen because it had gcc by default that i needed to compile the Wi-Fi drivers and i simply couldn't install gcc without it, because even if i got the .deb packages, they have their own dependencies that also need to be installed, which could not be collected by any sort of script that i could find.

I am using Thunar, which came as the default file manager with the distro of Linux Mint with the XFCE desktop that i installed:

My plan was to use a 64 GB SD card for storage, since the built in 32 GB get eaten up by the software that i'm using and god forbid i try to install node_modules for my projects on there:

I specifically chose the options to automount the devices that are plugged in, so that i could use them right after starting up the laptop and so that Nextcloud could also synchronize the data that i need to persist to the cloud and access it:

The problem is that this simply doesn't happen after boot and i need to mount it manually. Until then, Nextcloud won't find the sync folder and simply won't work:

I need to click on it manually, to mount the partition, which is when it starts to work. What's worse, sometimes the SD card will simply "break" inside the OS - the partition will become inaccessible and errors will get thrown. I actually attempted to screenshot this earlier today, but the screenshot itself got corrupted, oh the irony:

Of course, there are also occasions when it just freezes and my attempts to unmount it produce yet another error. In those cases, i've needed to restart the computer, which can be a bit difficult when it literally freezes on the splash screen when shutting down.

Could it be a bad RAM issue? A bad CPU, perhaps? Frankly, i have no idea, but it doesn't seem 100% random, since some software triggers these failures more often, such as intense Nextcloud sync with many different files. Actually, trying to run the Unity Editor seemed to reproduce this almost always, even though i don't feel like re-downloading all of it now just to get a screenshot of the error message.

A bit later, i actually found another screenshot, since this had been annoying enough for me to screenshot it multiple times:

System call failed? Maybe it's a kernel bug? I'm completely clueless.

I even tried creating a script to reproduce the conditions by slamming the SD card with parallel I/O load, but attempting to save 1 GB of 1 MB files simply didn't work well enough to make it break:

#!/bin/bash

echo "Cleaning up old files..."
rm -f ./random-file-*

for i in {1..1000}
do
  echo "Writing file $i"
  dd if="/dev/urandom" of="random-file-$i" bs=1000000 count=1 & # parallel
done

Update

Seems like the SD card finally died totally and isn't even detected by the laptop. Thankfully, it seems like the problems were a canary (some files were corrupted while copying as well), so by now all of them were backed up elsewhere.

A possible cause for these problems also could have been my laptop's varying support for microSD, microSDHC, microSDXC cards, so the next one i'll get will be a microSDHC card with just 32 GB of capacity instead of 64 GB.

It's also possible that some problems were caused by me using a journalling file system (ext4) because the journalling functionality, while a bit more tolerant to power loss and other failures, might cause too many reads and writes. Using ext2 which apparently doesn't have journalling, or just regular FAT32 might be a better idea.

Though i can only speculate.