Un disque de mon NAS se met à décrocher son lien SATA en boucle, à peu près toutes les 50 secondes. dmesg :
ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
ata2: SError: { PHYRdyChg }
ata2.00: failed command: FLUSH CACHE EXT
ata2: hard resetting link
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: configured for UDMA/33Le lien tombe (PHYRdyChg), une commande d’écriture est perdue en route (FLUSH CACHE EXT), le noyau fait un hard resetting link, et le lien remonte… en 1.5 Gbps (au lieu de 6.0). Puis ça recommence. C’est aussi audible : le disque fait des cycles moteur à répétition.
Le réflexe serait de condamner le disque. Ce serait une erreur.
Diagnostic : trois questions, dans l’ordre
1. Est-ce un seul disque, ou tout le contrôleur ?
sudo dmesg | grep -c "ata1.*PHYRdyChg" # 0
sudo dmesg | grep -c "ata2.*PHYRdyChg" # 4Seul ata2 décroche, ata1 est parfait. Donc ce n’est pas un problème global de contrôleur ni de configuration système — c’est spécifique à ce lien.
2. Est-ce le link power management (ALPM) ?
L’ALPM agressif est une cause classique de PHYRdyChg : le noyau met le lien en basse conso, certains couples disque/contrôleur le supportent mal.
for h in /sys/class/scsi_host/host*/link_power_management_policy; do
echo "$h = $(cat $h)"
done
# tous = max_performanceDéjà en max_performance → l’ALPM n’y est pour rien. (Si ça avait été min_power ou medium_power, un echo max_performance > … aurait pu régler l’affaire.)
3. Signal ou alimentation ? Le SMART tranche.
sudo smartctl -d sat -A /dev/sdX | grep -iE "UDMA_CRC|Pending|Reallocated"
# 199 UDMA_CRC_Error_Count ... 0UDMA_CRC_Error_Count = 0 est la clé. Des erreurs CRC signeraient un câble qui corrompt les bits en transit. Zéro CRC + des PHYRdyChg = le lien ne se corrompt pas, il tombe entièrement. Ça pointe vers une perte de contact ou d’alimentation, pas un défaut de signal ni de média.
La preuve : tester le disque ailleurs
Pour confirmer que le disque est sain, je le sors et je le branche sur un PC via un adaptateur USB-SATA (un lien totalement différent de la baie du NAS) :
sudo dd if=/dev/sdX of=/dev/null bs=1M count=5000 status=progress
# 5.2 GB copiés, 23 s, 221 MB/s
sudo dmesg | tail # aucun reset, aucune erreur5 Go lus à pleine vitesse, zéro erreur, SMART propre. Le disque est irréprochable. Le défaut est donc côté NAS : baie, câble, backplane… ou alimentation.
Dans mon cas, l’alimentation du NAS a fini par lâcher complètement quelques minutes plus tard. Le fin mot de l’histoire : une alim en fin de vie, incapable de tenir la tension pendant le spin-up d’un disque récent plus gourmand, faisait décrocher le PHY. Tous les symptômes (PHYRdyChg, chute à 1.5 Gbps, cycles moteur) découlaient de ça — pas du disque.
Lessons learned
PHYRdyChg+UDMA_CRC_Error_Count = 0= le lien tombe, il ne se corrompt pas → alimentation ou connexion, pas le média.- Une renégociation qui retombe à 1.5 Gbps après des resets = libata qui réduit la vitesse pour stabiliser → symptôme d’instabilité physique.
- Isoler par élimination : un seul port touché écarte le contrôleur ;
link_power_management_policyécarte (ou incrimine) l’ALPM. - Tester le disque suspect sur une autre machine (USB-SATA +
dd+smartctl) est le test décisif avant de commander un RMA. Cinq minutes, zéro ambiguïté. - L’alimentation est un coupable sournois : sous une alim marginale, c’est presque toujours le disque qu’on accuse à tort — surtout au moment d’un spin-up.