Bonjour

J'aimerais avoir votre avis sur la raison que j'ai obtenu des erreurs sur mon disque SSD 2.5". Je vais essayé d'être le plus précis et surtout concis.

L'architecture :
- un RPI 4 4Go sur lequel il y a une sd-card sur laquel j'ai installé une Debian
- sur la SD-card :
   - le serveur Web nginx, la base mariadb, php-fpm 7.4
   - un NextCloud
   - un portail photo Piwigo
- un SSD :
   - 250Go, de marque Corsair
   - Montage /dev/sda1 ==> /mnt/ssd
   - Liens symboliques depuis les répertoires de données de mon Piwigo et NextCloud vers le SSD (pour éviter de changer les paramétrages)

Le raspberry4 est alimenté via le bloc d'alimentation officiel (si ma mémoire est bonne du 3A). Le disque SSD est relié avec RPI4 grace à un cable USB/SATA que j'avais acheté chez Kubi. Il est disposé sur du parquet sous une étagère pour se faire discret.


Les actions faites dernièrement :
J'étais en train de faire un peu de dev sur mon piwigo pour rajouter pour ajouter des descriptions. J'ai donc pas mal uploadé des mises à jour de fichiers PHP puis d'un seul coup, après je me suis appercu que les photos n'est plus visible sur mon portail. J'ai fais un ls sur mon point de montage et il me répondait qu'il était vide, ou tout du moins une petite erreur dont je me suis souviens plus exactement.


Démontage du disque :
Puis j'essaie de démonter mais je ne peux pas sur le moment, j'obtiens un message "target busy". J'essaie d'arrêter tous les services, nginx, mariadb. J'obtiens toujours l'erreur target busy. Et j'y arrive après un  "lsof /media/dsk" qui normalement n'a aucun rapport.


Reboot puis fsck
Je reboot mon rpi, le SSD est automatiquement reconnu via lsbl. Je fais un fsck et la malheur :


les logs syslog, je peux voir :
Feb 17 17:24:56 rpi4-20210823 kernel: [10296229.853197] EXT4-fs error: 14 callbacks suppressed 
Feb 17 17:24:56 rpi4-20210823 kernel: [10296229.853206] EXT4-fs error (device sda1): __ext4_find_entry:1534: inode #2: comm php-fpm7.4: rea 
ding directory lblock 0 
Feb 17 17:24:56 rpi4-20210823 kernel: [10296229.859834] EXT4-fs error (device sda1): __ext4_find_entry:1534: inode #2: comm php-fpm7.4: rea 
ding directory lblock 0 

J'ai plein de ligne d'erreur comme ci-dessus depuis que je sollicitais mon RPI4 pour y faire du dev.


Pourquoi ?
Le RPI4 est peu sollicité, je n'ai même pas donné l'url à des potes. Je fais juste des upload automatique avec le client Nextcloud Android pour sauvegardé mes photos de mon téléphone. J'ai fais de même pour le téléphone de mon père.

J'ai l'impression que cette erreur est survenue dès que je l'ai sollicité un peu plus dès que j'ai fais du DEV, et encore les fichiers PHP sont sur la sd-card. J'ai fait pas mal de rafraîchissement de ma page Web pour voir le résultat à chaque fois. C'est à ce moment là que j'ai sollicité des accès au SSD.


Je suis absolument dégouté, je pensais être à l'abris de ce genre de mésaventure en privilégiant l'écriture sur un SSD qui est normalement plus fiable qu'une SD-CARD mais c'est tout l'inverse. Je ne comprends pas. Le SSD est sur un parquet, le flux d'air n'est pas bloqué.

Je ne sais pas quoi faire !! Si je me rachète un SSD, je sens que je vais avoir le même problème. Qui serait le fautif ?

Je me dis que c'est le cable usb => sata ? Il ne m'a couté bien cher, dans les 7euros alors qu'en boutique, il est bien plus cher. Chez LDLC, les cables coutent au moins 12-13 euros.
Le cable Kubii : https://www.kubii.fr/hub-cables-adaptateurs/3151-adaptateur-usb-vers-sata-3272496304642.html

Dois je abandonné l'idée d'hébergé mon Piwigo et NextCloud ?
Je trouve dommage avec les upload de folie que l'on a de nos jours...

Bonjour,
Que donne le diagnostique du SSD ?  (smartctl -a)

Mais de manière globale, les SSD sont plus fiables que les disques dur à plateau, je trouve.

Oui, malgré tout ça arrive les SSD qui fatiguent.
Sur un vieux PC, je n'ai pas de souci d'intégrité FS, mais smartctl m'avertit depuis quelques jours.
$ sudo btrfs device stats -c /
[/dev/sdb4].write_io_errs    0
[/dev/sdb4].read_io_errs     0
[/dev/sdb4].flush_io_errs    0
[/dev/sdb4].corruption_errs  0
[/dev/sdb4].generation_errs  0

$ sudo smartctl -a /dev/sdb|grep -iE "failing|model"
Model Family:     Samsung based SSDs
Device Model:     SAMSUNG MZMPC032HBCD-000H1
173 Wear_Leveling_Count     0x0013   017   017   017    Pre-fail  Always   FAILING_NOW 3022


je ne vois pas ce qu"il y a d'anormal
un ssd peut lacher tout autant que disque a plateau

t'en aurais eu deux de suite qui lachent, là ok tu peux te poser des questions mais là comme ca, c'est juste la vie.

je ne vois pas ce qu"il y a d'anormal
un ssd peut lacher tout autant que disque a plateau

t'en aurais eu deux de suite qui lachent, là ok tu peux te poser des questions mais là comme ca, c'est juste la vie.

Exactement, c'est l'intérêt de faire du RAID 1 pour prévenir les pannes de disques. Et surtout il faut faire des sauvegardes régulières sur d'autres types de médias.

Je viens de changer deux BX500 sur un serveur à la maison. Les valeurs SMART se sont mis à raconter des choses incohérentes. Avant de tout perdre, j'ai changé les disques par des Samsung tout neufs qui trainaient sur l'étagère. Un des deux BX500 fait du bruit quand je le secoue 🙃 Il va falloir que je l'ouvre pour voir ce qui provoque ça.

Il y a quelques mois, c'est un 860EVO qui m'a lâché au redémarrage d'un PC, sans signe avant-coureur si SMART défaillant. Il est passé en garantie Samsung qui m'a renvoyé un 870 en échange. Une restauration de sauvegarde, et le tour est joué.

Le BX500 est un SSD premier prix en TLC assez lent, comptant sur un gros cache SLC pour compenser, plutôt sensible à l'absence de Trim et à l'amplification d'écriture. Vraiment pas ce que je mettrais dans un serveur   Le MX500 est bien plus robuste.