A segunda coisa que eu procurei foi o acesso direto ao dispositivo. sudo lsof /dev/sd* não mostrou nada. cd /dev; fatrace --current-mount --timestamp não mostrou nenhum acesso associado.
Neste ponto, eu precisava começar a desmontar o kernel. Vamos tentar systemctl isolate rescue.target . Estranho, ele volta para default.target . Então systemctl status mostra que o sistema está degradado porque dmeventd não queria parar enquanto ainda está monitorando dispositivos (!) ... mas o disco rígido parou de girar de volta (!!).
De fato, em um sistema não degradado, o problema desaparece após killall -9 dmeventd .
Como pode ser tão quebrado? O motivo é que eu comecei a brincar com docker e, como eu uso o LVM, ele escolheu o driver de armazenamento devicemapper. [*]
dmeventd[5054]: dmeventd ready for processing.
lvm[5054]: Monitoring thin vg_fossil-docker--pool.
[*] Também pode ser um problema se você tiver espelhos LVM, raid ou snapshots ... reconhecidamente uma possibilidade em um sistema NAS :(. Se você não tem nenhum desses, por exemplo, apenas LVs simples ou sem LVM, então o dmeventd não tem nada para monitorar e se comporta.
Especificamente, o dmeventd faz esses ioctls a cada 10 segundos:
open("/dev/mapper/control", O_RDWR) = 7
...
ioctl(7, DM_TABLE_STATUS
ioctl(7, DM_DEV_WAIT
Eu ainda acho que o spinup é um bug, mas pelo menos no meu caso há uma solução óbvia [*] e eu não estou realmente preocupado de perder nada por causa disso.
[*] Se você realmente quiser impedir que o dmeventd funcione, mesmo que você tenha um thin pool que provavelmente morre horrivelmente se ficar sem espaço, pesquise por monitoring = 1 em lvm.conf e altere o valor para 0 .
Atualização: O bug foi corrigido na próxima versão de lvm2 , 2.02.133 .