It’s unrelated to the issue, but since it came up in the course of conversation:
I was curious and checked for a (to me) random address in NL and got ~€ 28,- to € 30,- per month or about € 0,29 per kWh
… not € 1,00 
Perhaps you urgently need to change your provider if they are truly charging you that much - which is easy in Germany - looks like it is the same in NL.
Cheers
I did set the hdparm’s -S option to 253 which, according to the man page, should set a vendor-specific spin-down delay of 8 or 12 hours. Watching the messages that appear at boot, it Linux doesn’t spend extra time on a startjob for that drive.
I spoke with my hardware guy, and he recommended that I reformat that partition.
I should indeed urge him to come over and help me with the cable switch test. I did address that, but he didn’t believe that that was the issue.
Alright, waiting then for updates. At least you could rule out a hardware issue in your case by testing the cables, switching ports, etc…
Well… this error has nothing to do with the file system. Really.
I feel that you’re right about this not being a FS issue, @megavolt. In fact, I compared the fstab records for the faulty drive with that of the other one in my computer, and they are identical. Filechecks, fixing bad blocks and restoring the superblock don’t have any effects.
Unless this thread is being closed before he can come over ofc, I’ll report back here and tell if we managed to fix, or at least locate the culprit.
Any setting like this does not survive a reboot.
The drive does not remember it, AFAIK.
You can yourself put the command in some startup script.
If it worked, if the drive reacted as you expected.
There is the -K option, but your drive may not support it.
The exact command that I issued was:
sudo hdparm -B254 -S253 -K1 /dev/sda
I didn’t know that there are drives that don’t support that flag. I’ll try putting it in cron then, telling it to run at boot.
I didn’t know either - I just read the manual page 
update:
I did a filecheck on the ailing partition (# e2fsck -fy /dev/sda4), as I did several times before, and it corrected some block sizes in stage 5. Then I repeated it, and this time, nothing was changed.
But now, somehow the time-outs are gone, while the dmesg messages still persist. Imo, this confirms that a connection is the cause of the issue, and that it may happen any time again.
I’d like to have a second opinion on this matter.
There where two already
Did you try ruling out a faulty cable?
I still hould have my friend come over to check it out. May be a while since he lives in another town. But a faulty cable or dito connection is my current hypothesis indeed. For now, until he can come over, I’m happy enough that the 10 sec time-outs are gone.
My friend’s finally come over. He fixed a broken ata port; the capping broke off when the motherboard was installed. He made sure that the wires were not touching. And he replaced the ata cable with a new one.
Now, the issue appears to be pretty much over. Still need to do some checks, for sometimes it’s still a bit sluggish (perhaps because it’s an 18 GB partition), and it spins down very rapidly yet.