Ça va être marrant de voir les temps de reconstruction des raids avec des disques de 50 To.
Pour tester l'état de disques durs :
sudo apt install smartmontools gsmartcontrol
gsmartcontrol est une interface graphique pour un affichage un peu plus clair des statistiques, et pour effectuer les tests rapidement.
Et sinon il y a toujours la ligne de commande ;-)
Des précisions de Western Digital :
@antichesse Je parlais de mon expérience personnelle, ayant acheté près d'une quarantaine de disques durs (de 500Go à 10To) au cours des 15 dernières années. J'ai monté mon propre NAS maison vers 2008/2009 avec 13 disques de 1 To WD Black en RAID5/ext4 et mdadm, et les principaux soucis rencontrés étaient plus dûs à la jeunesse de ext4 que autre chose.
Pour le reste, c'est vrai que mon utilisation se rapproche plus du stockage froid que de l'utilisation intensive. Mais disons que pour l'instant je n'ai pas vécu les mauvais côtés décrits.
La partition / de mon PC commençait sérieusement à manquer d'espace aujourd'hui (moins de 1.5 Go disponibles). J'ai donc cherché partout la raison de ce remplissage. D'autant que j'ai partitionné mes disques de telle façon que le / n'ai aucune raison de se remplir sans une action directe de ma part (mises à jours, ajout volontaire de fichiers, etc).
Et puis en utilisant un peu de magie (et un peu de find), j'ai trouvé l'immonde coupable : .xsession-errors !
Ce petit impertinent est un fichier de log qui recense les erreurs graphiques de tout un tas d'applications, et en particulier des gestionnaire de fenêtres (Nemo dans mon cas). Situé à la racine de mon home, il a réussi à gonfler jusqu'à prendre 4 Go !
Comme il s'agit d'un fichier de log, je me demande bien ce qu'il peut faire ici au lieu d'être, par exemple, dans ... /var/log
! Ça use mon SSD pour rien en plus !
Bref.
Pour désactiver l'écriture des logs dans ce fichier :
/etc/X11/Xsession
;ERRFILE=$HOME/.xsession-errors
;ERRFILE=/dev/null
Au lieu d'écrire dans le fichier, les logs iront maintenant se perdre dans le vide sidéral.
Un disque dur mécanique se met en stand-by après une certaine durée pour économiser de l'énergie. Résultat? Quand je souhaite y accéder, le moteur qui fait tourner les disques doit se remettre en mouvement, et cela prend toujours un certain temps (plusieurs secondes).
Pour régler le temps au-delà duquel le disque se met en "veille" je peux utiliser l'outil hdparm (Linux) :
# J'affiche les informations relatives au disque sda
sudo hdparm -I /dev/sda
Puis je regarde la ligne Advanced power management level.
Quelques infos sur ce nombre tirées de cette page (traduction du manpage) :
-S
Paramétrer le temps mort du stand-by de périphérique.Usage :
0 : désactive ; le périphérique ne rentrera pas en mode stand-by.
De 1 à 240 : spécifie des multiples de 5 secondes, avec des temps morts de 5 secondes à 20 minutes.
De 241 à 251 : spécifie de 1 à 11 unités de temps de 30 minutes chacune, avec des temps morts de 30 minutes à 5 h 30.
252 : spécifie un temps mort de 21 minutes.
253 : est une période de temps mort définie par le fabriquant, entre 8 à 12 heures.
254 : réservée !
255 : est interprétée comme 21 minutes plus 15 secondes.
Pour changer le temps de stand-by, il suffit d'utiliser correctement ces valeurs :
# Pour désactiver le stand-by
sudo hdparm -S 0 /dev/sda
# Pour le fixer à 2 minutes (5 secondes x 24)
sudo hdparm -S 24 /dev/sda
# Pour le fixer à 01h30 (30 minutes * 3)
sudo hdparm -S 243 /dev/sda
Attention: ne pas confondre avec l'option -s (minuscule) qui n'a pas du tout le même effet !
Sinon, tu pouvais :
- lancer gparted
Le disque n'apparaissait pas dans GParted. Tu penses bien que j'ai essayé avant de tenter la solution CLI.