It’s a disk designed for constant operation, thats why I want to prevent spindowns.
Even applying sudo hdparm -S 0 -B 255 /dev/sda once doesn’t stop the spindowns (I’ll now keep that command running in a loop in hope for some effect). I suspect something keeps messing with the drive APM/standby settings.
There must be a way to pin down the recently introduced behaviour. hdparm wasn’t installed when I first noticed the issue. What other components come to mind?
Well, anything power-related. Many distributions install those things by default. My test of Endeavour OS showed that it was completely set up with a laptop in mind, and I remember that when I installed Manjaro now six years ago, tlp was installed and active by default — I immediately removed it from my system, of course.
The only thing power-savings-related that I have active here is that my monitor will go into soft-power-off after a certain time of inactivity, or about 10 minutes after I lock the screen. Everything else remains full operational — no suspend-to-RAM or suspend-to-disk.
Go through your package list and uninstall anything power-related that isn’t a hard dependency of something else. 
I’d take a shot in the dark and try a different kernel. Just to rule that out.
A different kernel is always a good thing to try for things like this. Looking through the few hundred packages that got updated, (are you on Plasma?), I see a few that could affect this.
If you are on Plasma there were updates in:
- powerdevil
- solid
I’ll ignore..
Going through every package, I still think this is a likely candidate:
Or at least a udev rule from something. But I’ve been diffing everything in and around there, and all the rules, to no avail.
Why not try running with it disabled to see what happens.
sudo systemctl disable udisks2 --now
And obviously to undo that change, you would run:
sudo systemctl enable udisks2 --now
From the man page — “man udisks”, without the “2”… 
At start-up and when a drive is connected, udisksd(8) will apply configuration
stored in the file /etc/udisks2/IDENTIFIER.conf where IDENTIFIER is the value of
the Drive:Id property for the drive. If the file changes on disk its new contents
will also be applied to the drive. Typically, users or administrators will never
need to edit drive configuration files as they are effectively managed through
graphical applications such as gnome-disks(1). Manually editing configuration
files is however supported — the file format is a simple .ini-like format (see
the Desktop Entry Specification[3] for the exact syntax). New groups and keys
may be added in the future.
[...]
APMLevel
The Advanced Power Management level. A low value means aggressive power
management and a high value means better performance. Possible settings
range from values 1 through 127 (which permit spin-down), and values 128
through 254 (which do not permit spin-down). The highest degree of power
management is attained with a setting of 1, and the highest I/O performance
with a setting of 254. A value of 255 can be used to disable Advanced
Power Management altogether on the drive (not all drives support
disabling it, but most do). This is similar to the -B option in hdparm(8).
I’m sure it was disabled on my host system because it was waking up my SATA HDDs. 
So I don’t use it, I was just trying to brainstorm possible packages.
Before I posted, I did catch that from the Arch wiki.
https://wiki.archlinux.org/title/Udisks#Apply_ATA_settings
Made me think it was a possibility when glancing..
But that /etc/udisks2/_identifier_.conf file would have to exist, which is probably unlikely.
Thanks for all the input.
I temporarily disabled both udisks2 and upower to see if they had any impect, they didn’t.
upower doesn’t seem to have any capability to send ATA commands (for APM or standby/spindown purpose) at all.
udisks2 has such a feature, but it has to be configured explicitly. I even tried that as described in the arch wiki to see if it could solve my issue by creating /etc/udisks2/TOSHIBA-MG10ACA20TE-1470A0D3F4MJ.conf with the following content:
[ATA]
StandbyTimeout=0
APMLevel=255
without any success. I really wonder why this doesn’t apply correctly. Maybe it does, but gets overridden by another service immediately.
Regarding powerdevil I don’t see any option to configure harddisk timeouts. It only seems to handle system standby and monitor standby.
I’ll observe it with another kernel, however I’m unsure if such a change in behaviour would be introduced in a minor patch update while not also affecting other kernel branches (if we talk about backports).
The issue still exists.
Did you run “systemctl daemon-reload” (or reboot) after creating the file?
I restarted the service but I also rebooted afterwards to check the results.
As a last resort I now configured a systemd timer to apply hdparm -S 0 -B 255 to my drive every minute. It’s ugly and I hate it, but it works.
It seems like I have to battle another daemon constantly trying to set aggressive power-saving values by itself. I’m still eager to find out whats the fundamental issue here.