Why one of two HDDs wakes from sleep during the first Linux graphical login?

Question

I have two archive HDDs, which I use very infrequently (I mount their partitions manually less than once a week on average). Since I turn my computer off at night, I tried to prevent them from spinning up on everyday's boot, but that seems way too difficult: requires patching the Linux kernel. As a worse but simpler alternative, I created a simple systemd unit that puts the HDDs to sleep immediately after boot (ExecStart=/usr/bin/hdparm -Y /dev/disk/by-id/... and WantedBy=multi-user.target). This almost works: both disks spin down upon boot. I verified this by a terminal login in tty2: sudo hdparm -C /dev/sd[bc] reports drive state is: standby.

However once I log in a graphical shell, one of the disks spins up audibly and hdparm reports drive state is: active/idle for it. This happens both with XFCE and KDE Plasma 5 (Manjaro GNU/Linux with latest updates), and also with another user of the same system. After the disk awakens, I put it to sleep manually (hdparm -Y ...), and it never wakes again until I reboot the computer. Logging out, then in, even as another user, doesn't wake any of the disks again.

This awakening disk is always the same. I tried to swap SATA cables of these two HDDs, which exchanged their IDs (sdb<->sdc), but still the same physical HDD is awakened upon the first graphical login. This awakening disk is definitely not mentioned anywhere in my configuration files by its permanent ID because I purchased it recently (second-hand). More specifically, the disk that keeps sleeping is Samsung HD103UJ and the disk that awakens upon the first graphical login is Samsung HD154UI.

I am monitoring /dev/sd[bc] accesses with auditd. The logs are practically the same for both disks. First I log in the tty2 console and run sudo hdparm -C /dev/sd[bc]: both disks are sleeping; then I switch to tty7 and log into XFCE from the lightdm screen; I quickly switch to tty2 and now one of the disks is no longer sleeping. The essence of the sudo ausearch -f /dev/sdb command output corresponding to these events:

comm="hdparm" exe="/usr/bin/hdparm"
comm="udisksd" exe="/usr/lib/udisks2/udisksd"
comm="hdparm" exe="/usr/bin/hdparm"
comm="udisksd" exe="/usr/lib/udisks2/udisksd"
comm="pool" exe="/usr/lib/udisks2/udisksd"
comm="pool" exe="/usr/lib/udisks2/udisksd"
...

And so on. The comm="pool" line appears every 10 minutes in the log, or more often while gnome-disks is running, but the comm="udisksd" line doesn't appear until reboot. Assuming that auditd reports all disk accesses, this comm="udisksd" must be responsible for the waking up. But why only one of the 2 HDDs? Perhaps the offending HDD can be configured with hdparm not to awaken?

I compared hdparm -I /dev/sdb and hdparm -I /dev/sdc outputs with meld. Also tried -Iv, -i and -iv options instead of -I. The differences are pretty much limited to unique identifiers, disk sizes, geometry. The only difference that could cause this wake-up inconsistency is the Firmware Revision: 1AA01118 on the non-waking disk and 1AG01118 on the waking one.

Answer 1

udisksd calls dumpe2fs -h /dev/sd?? command for each ext2, ext3 and ext4 partition when the service is started and when it mounts/unmounts any disk. My awakening HDD contains an ext4 partition and so is waked by udisksd =>dumpe2fs. The other HDD does not have any ext* partitions and so is never waked by udisksd.

Much more details can be found in comments to this udisks bug: https://github.com/storaged-project/udisks/issues/611. The bug is fixed in udisks 2.8.4, so it no longer wakes any HDDs when an unrelated partition is mounted or unmounted. The same HDD is still waked when udisksd starts, so I have to keep the second systemd unit that puts this HDD to sleep after the udisks2 service is started.