Archlinux.fr [Forums]

Bonjour à tous !

Le "récit" ci-dessous est sans doute inutilement long, mais je ne suis vraiment pas sûr d'avoir identifié ce qui se passe, donc je préfère en dire trop que pas assez, peut-être que quelqu'un y décèlera un "indice".


Ça fait un moment que mon serveur HP MicroServer me fait des caprices quand je le reboot. Dès quelques mois après sa mise en place, presque à chaque fois que je redémarrais après un pacman -Syu plus ou moins mensuel, il ne redémarrait pas normalement. J'avais partagé mes péripéties dans un premier fil, dès octobre 2013. En résumé le système démarrait en rescue et réclamait un fsck pour la partition système, se trouvant sur un SSD.

Le SMART était bon mais je m'étais rendu compte que je n'avais pris aucune mesure particulière pour un SSD. J'avais alors activé le TRIM en utilisant le flag discard dans le fstab. Il me semble que ça avait mieux fonctionné quelques temps.

Le mois dernier il m'a refait le coup. J'avais donc lancé fsck, qui m'avait fait corriger des dizaines d'erreurs. Il avait fallu que je re-choisisse le SSD comme premier support de stockage sur lequel démarrer dans le BIOS. Puis c'était reparti. Je n'avais pas pris le temps de creuser.

Rebelote cette semaine : fsck, reconfiguration du BIOS, redémarrage avec succès. Je profite d'avoir écran et clavier branchés (la machine est habituellement headless) pour faire un pacman -Syu et voir s'il s'en sort. Mais au redémarrage après l'affichage de "Booting the kernel.", rien ne se passe pendant 5 min. Je force le redémarrage, je vois des messages d'erreurs liés au stockage, à nouveau un fsck obligatoire. Au redémarrage suivant, il démarre à nouveau en rescue et j'obtiens le message "Could this be a zero-lenght partition?". Je redémarre encore et cette fois c'est le SMART qui se manifeste et m'indique "BAD".

http://i.imgur.com/Oahdb4p.jpg
http://i.imgur.com/AgrdLAP.jpg

Je crois comprendre que le SSD est mort. C'était un Crucial V4 de 32 Go, donc un ancien modèle d'entrée de gamme et de petite capacité.

Est-ce que je suis simplement tombé sur un modèle défaillant ? (ce qui me semble étonnant, généralement soit ça tombe en panne rapidement, soit ça fonctionne très longtemps) Ou bien est-ce que je n'ai pas pris les mesures nécessaires pour le préserver ? Je n'ai pas touché à la configuration des logs par exemple, auraient-ils entraîné de tels volumes d'écritures que j'ai déjà fais le tour des cellules ?

Ce SSD et ce qu'il contenait n'est pas une grande perte, je n'avais aucune donnée personnelle dessus, seulement des fichiers de configuration que je devrai refaire. Mais avant de racheter un nouveau SSD ou même un nouveau disque dur, j'aimerais comprendre quelle a été mon erreur pour ne pas recommencer. Quelqu'un a une idée ?


Il y a tout plein d'autres photos ici :
http://imgur.com/a/smbmU

Je retiens de ton post, Crucial V4. Une recherche à la fainéante m'amène ici:
http://www.comptoir-hardware.com/actus/ ... iter-.html

Je n'ai aucun SSD et je me demande justement si c'est une bonne affaire d'en avoir et de les utiliser ?

PS: j'ai trouvé quelques longs articles détaillés à décortiquer à temps choisi:
http://libre-ouvert.toile-libre.org/?ar ... t4-noatime

http://forum.hardware.fr/hfr/OSAlternat ... 9473_1.htm

Pas de SSD chez moi.

Il me semble que le truc auquel il faut vraiment faire gaffe est de désactiver la conservation du dernier temps d'accès. À chaque accès, les systèmes de fichier écrit sur le disque le temps d'accès. Pour des fichiers beaucoup accédés, cela fait pas mal d'écritures sur les mêmes bits des secteurs concernés. Les mémoires Flash des disques SSD sont qualifiées pour un certain nombre d'écriture (1000 ? 10000 ?), donc une mise à jour du temps d'accès à chaque accès a tendance à flinguer le disque.

Il me semble que ça se bloque avec un flag noatime dans le fichier /etc/fstab.

Il y a pas mal d'infos (en Anglais) ici :
https://wiki.archlinux.org/index.php/SS ... d.2FWrites
(ça pourrait peut-être t'aider à savoir ce que tu aurais pu faire différemment)

mélodie a écrit :Je retiens de ton post, Crucial V4. Une recherche à la fainéante m'amène ici:
http://www.comptoir-hardware.com/actus/ ... iter-.html

J'avais lu des tests lors de l'achat, peut-être bien celui d'AnandTech dans le lot, et aucun ne soulevait d'inquiétude quant à l'endurance de ce SSD. Il n'est question que de piètres performances, ce qui ne me gênait pas, même pour économiser seulement 5 euros.

mélodie a écrit :PS: j'ai trouvé quelques longs articles détaillés à décortiquer à temps choisi:
http://libre-ouvert.toile-libre.org/?ar ... t4-noatime

http://forum.hardware.fr/hfr/OSAlternat ... 9473_1.htm

Ces deux articles sont très intéressants, je les ai "bookmarkés", merci.

bobo a écrit :Il me semble que le truc auquel il faut vraiment faire gaffe est de désactiver la conservation du dernier temps d'accès.

Code : Tout sélectionner

$ stat .bashrc 
  Fichier : « .bashrc »
   Taille : 1954      	Blocs : 8          Blocs d'E/S : 4096   fichier
Périphérique : 802h/2050d	Inœud : 656555      Liens : 1
Accès : (0644/-rw-r--r--)  UID : ( 1000/    bobo)   GID : (  100/   users)
 Accès : 2014-05-29 10:59:18.395274711 +0200
Modif. : 2014-05-21 21:51:46.422092271 +0200
Changt : 2014-05-21 21:51:46.448757961 +0200
  Créé : -

À chaque accès, les systèmes de fichier écrit sur le disque le temps d'accès. Pour des fichiers beaucoup accédés, cela fait pas mal d'écritures sur les mêmes bits des secteurs concernés. Les mémoires Flash des disques SSD sont qualifiées pour un certain nombre d'écriture (1000 ? 10000 ?), donc une mise à jour du temps d'accès à chaque accès a tendance à flinguer le disque.

Il me semble que ça se bloque avec un flag noatime dans le fichier /etc/fstab.

Il y a pas mal d'infos (en Anglais) ici :
https://wiki.archlinux.org/index.php/SS ... d.2FWrites
(ça pourrait peut-être t'aider à savoir ce que tu aurais pu faire différemment)

C'est sur cette page du Wiki que je m'étais reposé lors de ma première panne. J'avais donc activé discard et noatime. Et lors de l'installation j'avais pris soin d'aligner les partitions. Merci malgré tout pour le conseil, car tous les tutoriels ne suggèrent pas le flag noatime.

Autrement dit à la lecture de vos 4 liens, je crois avoir suivi tous les bons conseils en matière de SSD, et j'ai du mal à comprendre pourquoi j'ai une panne maintenant, 1 an 1/2 après l'achat. Comme je le disais ça me semble être trop tard pour un défaut de fabrication, mais trop tôt pour une usure "normale".

Du coup j'hésite à revenir à un disque dur, mais ce serait vraiment dommage puisque pour le prix d'un disque dur premier prix, j'ai un SSD de capacité bien suffisante et autrement plus performant, silencieux et économe en énergie.


Savez-vous comment sont gérés les logs sur le plan du stockage ? Est-ce qu'ils sont maintenus en mémoire vive un moment puis écrits par lots ? Est-ce que le fichier entier est ré-écrit ou est-ce que seulement les dernières lignes le sont ? Savez-vous si on peut paramétrer syslog pour qu'il sollicite moins le support de stockage ?

Bonjour,
Aujourd’hui il est préconisé de ne pas utiliser l'option discard, mais fstrim via cron.
De plus utiliser syslog en plus de journald de systemd n'est pas une bonne idée. Tu pourrais même n'utiliser que le journal en mémoire de systemd en désactivant l'écriture dans /var/log/...
Les SSD de petite capacité s'use plus vite, je dirai qu'il est conseillé de ne pas trop le remplir, en gros avoir 6 Go de libre sur chaque partition n'est pas une mauvaise idée.

Sinon dans ma boite 2 SSD sur 2 "serveurs" fournit à un client sont tombés en panne plus ou moins en même temps après même pas un an... Cela arrive, ils sont sous garantis...

benjarobin a écrit :Bonjour,
Aujourd’hui il est préconisé de ne pas utiliser l'option discard, mais fstrim via cron.
De plus utiliser syslog en plus de journald de systemd n'est pas une bonne idée. Tu pourrais même n'utiliser que le journal en mémoire de systemd en désactivant l'écriture dans /var/log/...
Les SSD de petite capacité s'use plus vite, je dirai qu'il est conseillé de ne pas trop le remplir, en gros avoir 6 Go de libre sur chaque partition n'est pas une mauvaise idée.

Sinon dans ma boite 2 SSD sur 2 "serveurs" fournit à un client sont tombés en panne plus ou moins en même temps après même pas un an... Cela arrive, ils sont sous garantis...

C'est noté pour fstrim, merci pour le conseil.

Je me suis trompé, je n'ai jamais touché à la configuration des logs systèmes donc j'utilise journald. Et je ne les consulte pour ainsi dire jamais, c'est plutôt avec mes services que j'ai des soucis à diagnostiquer, le système fonctionne bien. Je désactiverai donc l'écriture dans /var/log quand je réinstallerai le système, merci encore !

Le SSD ne fait que 32 Go mais il est très loin d'être saturé, il n'y a que le système dessus. D'où l'incompréhension. Mais bon je ne pense pas avoir fait d'erreur, il semble que ce soit une panne "naturelle", donc je vais racheter un SSD plus fiable (un SanDisk SSD de 64 Go) et repartir à zéro.

Il faudra seulement que je sois très prudent avec la récupération de mes volumes mdadm et LVM, je n'ai malheureusement pas de quoi sauvegarder tout ce qui craint. Dire que j'étais à quelques jours de reconfigurer une sauvegarde hors site… :-) Toutefois, est-ce qu'un live Ubuntu par exemple remontera automatiquement ces volumes pour que je puisse les copier sur un disque dur USB ?