Dans la nuit de vendredi à samedi, mon SSD a rendu l’âme.
Plus de réponse de Jeedom et un défilement continue sur l’écran avec le message suivant :
EXT4-fs error (device sda2) : ext4_find_entry 1536 : inode #54xxx …. reading directory lblock 0
Etc… Reboot idem.
Bref pas de panique, il y a les sauvegardes sur le Nas et j’ai une image du système datant de ma réinstallation en septembre.
Je vérifie le SSD sur mon PC avec un utilitaire disk et je vois effectivement un nombre important de cellule dite ‘morte’ et que la quantité de lecture et d’écriture sur le disque est énorme.
J’avais upgradé mon Jeedom sur un PI4 et un SSD en janvier (un SSD de 120Go venant d’un pc portable peu utilisé, je l’avais remplacé par un ssd de 500 Go.) , j’avais installé Buster et Jeedom sur une partition de 16Go, il n’y pas besoin de plus et ça limite la taille des images de sauvegarde à 16G.
Mes interrogations sont donc les suivantes :
Un SSD est censé faire une rotation de ses cellules lors des écritures !
Mais le fait-il sur toutes les cellules du disque, donc sur les 120Go ou seulement sur les cellules de sa partition de 16Go ? Si c’est le cas, on n’aurait pas beaucoup plus de fiabilité qu’avec une carte SD.
Ensuite la fonction TRIM, censée effectuer cette rotation, est-elle activé par défaut sur les images ?
Même avec un trim (pas activé par défaut sur Debian, sur les images jeedom je ne sais pas) un ssd pro est conseillé sinon avec une bdd en direct ça s’use très vite.
C’est moins le cas via une VM d’après mon expérience perso.
Ayant eut quelques soucis avec mon msata au bout d’un an (je soupçonne le cable) je suis sur une carte SD 16go depuis plus d’un an et aucun soucis (j’ai juste mis un onduleur)
Pour confirmer, ça dépend beaucoup de la ref du matériel, ainsi que son utilisation.
J’ai des pi qui tiennent très bien sur des SD et hors SSD exotique, je n’ai jamais eu aucun soucis à ce niveau
Ah oui je ne parle pas de mon pi1 acheté à la sortie ou un peu près qui tourne toujours avec la même carte sd du début.
Mais il ne sert plus que de deuxième pihole
Ha oui moi aussi je tourne sur carte SD, et j’en ai une d’avance dans le tiroir au cas où j’en ai déjà changé une il y a 2 ans, c’est presque aussi rapide que changer la roue d’une voiture. Faut accepter de vivre dans la précarité, mais d’un autre côté on constate que les solutions sur SSD ça plante aussi parfois
c’est possible d’avoir plusieurs partitions virtuelles de 16Go sur 1 DD de 120Go et les monter en mode raid avec redondance ? je savais pas qu’on pouvait faire ça!
Pour écrire tout un double sur le même support donc deux fois plus lent, et ça l’use deux fois plus vite pour que de toute façon tout soit par terre s’il est défectueux ?
C’est quoi l’intérêt ?
C’est surtout l’inverse qui est vrais, plus le SSD est grand, plus son cycle R/W est grand.
Personnellement, j’ai deux SSD mSata de petite taille (32/64go) qui sont en service depuis 2018 sur Pi3B+ et maintenant Pi4.
Et 3Pi (3B+/3B/Pi ZeroW) qui vivent aussi depuis 2016/2017 avec des cartes SD qui sont d’époque (BLEA/Kodi, PiCorePlayer)
Les SSD ont une espérance de vie au delà des données constructeurs (je ne parle que des marques fiable).
=> Les SSD ont un ennemi : la coupure de courant !
Enfin l’intérêt du RAID est de pallier aux défaillances physiques des disques.
On peut peut-être (et encore je ne suis pas sûr) faire du RAID avec un disque partitionné mais si physiquement il crashe, je ne vois pas comment tu vas récupérer les partitions flinguées puisqu’elles sont toutes sur le même support physique.
Bonjour
Pour le moment je ne suis pas plus avancé, j’ai récupéré un SSD pro mais il consomme trop et ca plante. Je soupçonne aussi le boitier USB3, j’en ai recommandé un. En attendant je suis reparti sur la SD.
J’activerai le TRIM sur la prochaine installation mais si c’est géré par l’OS, j’ai peur que cela n’agisse que sur la partition de 16Go et pas sur le disque entier.