benoar a écrit 4272 commentaires

Donc au final, pour avoir un comportement satisfaisant il faut vérifier qu'il n'y a pas de process parasite et régler son délai avant parquage à une valeur adaptée à son utilisation.

Ah ok ; c'est juste que depuis le début je ne me concentrais que sur mon utilisation : là tu dois parler également de ceux qui utilisent un portable et qui veulent que le disque se mette en veille au bout d'un moment pas trop long sans process pour le réveiller trop souvent.

Comme process parasite rigolo, j'ai eu mon lot de surprises : firefox qui synchronisait toutes les 30s,

Ah, firefox qui fsync toute ta navigation… j'aimerais bien montrer la débilité de la chose avec un « vieux » smartphone qui freeze 10s (oui oui, 10s) à chaque visite d'un lien car il le sauvegarde dans l'historique, et je soupçonne que la cause est le contrôleur de la flash qui galère à mort à faire sa tambouille pour trouver de la place en flash… (contrôleur eMMC sans TRIM, je suppose). (ya un thread sur un autre journal là-dessus en ce moment)

des process qui loggaient pour pas grand chose (--mark-- dans syslog),

Oui, mais ça peut parfois être utile pour savoir qu'il ne s'est pas arrêté, peut-être.

des CRON se déclenchant toutes les heures sans réelle utilité, etc.

Oui. Si tu (on ?) pouvais remonter remonter ça upstream avec des bugreports sympas, afin de trouver une solution à ça, ça serait génial… :-)

Les FS modernes (ZFS, Btrfs, …) fournissent par défaut le copy on write et donc presque gratuitement, le premier point, la répartition des écritures sur l'ensemble du device.

Tout à fait. Vu qu'on s'en fout de la localité des accès sur un SSD, ce genre de fonctionnement n'est de plus pas pénalisant pour les SSD, contrairement aux disques classiques.

Ce qui supprime toutes la logique de garbage collection et de CoW au niveau du device.

Alors là pas du tout.

Mettons-nous dans le cas d'un SSD « complètement utilisé » (pas neuf) sans trim, i.e. sur lequel on a écrit au moins autant que sa capacité, et qui a donc tous ses secteurs marqués comme « occupés », quoiqu'en dise le FS dessus (même avec 100% d'espace libre) ; cas on ne peut plus classique pour un support de stockage utilisé normalement. Sa table (interne) de mapping des secteurs est faite d'une certaine manière, propre à sa manière de gérer la répartition des blocs et à l'utilisation qui en a été faite, et n'est pas forcément du tout contiguë par rapport aux secteurs tels qu'on les voit à plus haut niveau.

Quand une écriture pour le secteur S arrive, quel que soit la manière du FS d'écrire dessus, qu'il fasse du CoW ou autre, ton SSD va devoir trouver de la place pour l'écrire, à un endroit qui n'est pas le même que le précédent secteur qu'il remplace si c'est un FS style CoW, certes, mais de toute façon d'une manière où le SSD va devoir lui aussi changer son mapping car il y a beaucoup de chances qu'il doive déplacer tout un bloc (= plusieurs Mo) d'un endroit à un autre, en re-déplaçant d'autres secteurs au passage (= ré-écriture d'autres blocs également) afin de faire de la place (rappelons qu'il n'a plus de place libre, et qu'il doit donc trouver un endroit ou écrire = un bloc vierge dans son espace provisionné pour, dans lequel passera le secteur qui était précédemment présent à cet endroit selon le mapping du SSD). Tu n'as aucun contrôle sur le mapping interne du SSD, et même si tu voulais être optimiste et te dire qu'en faisant des écritures de la taille de « l'unité » qu'il utilise pour gérer son truc, ça serait « optimal », bah aujourd'hui les blocs c'est plusieurs Mo… (oui, il écrit par page, i.e. plusieurs centaines de Ko, mais je parle en erase-block pour simplifier)

Alors après, si ton contrôleur de SSD est pas trop con, il va pouvoir « agglutiner » plusieurs requêtes en écriture (tout en faisant gaffe à l'interaction avec la sémantique d'atomicité (ou pas) de la suite d'instructions qu'il reçoit) afin d'écrire des blocs plus gros, qui nécessiteront de moins faire de déplacement de secteurs, mais ça n'empêche qu'au final, la logique de garbage collection est au contraire beaucoup plus intense et compliquée, et ton amplification en écriture (= rapport de la taille de la requête en écriture / écritures réellement réalisées sur le SSD) est énorme, ce qui entraîne une dégradation de la durée de vie de ton SSD.

Pour ce qui est du 2ème point, il est toujours nécessaire mais ce n'est plus un trim, une opération potentiellement lourde**, mais juste un reset quand c'est fait au niveau du fs.

Je ne comprends pas ce que tu veux dire… tu parles d'un « reset » qui serait ton fstrim, mais fait régulièrement / automatiquement ?

Sur les FS non moderne (extX, …), la véritable question c'est plutôt : « quand faire le trim ? A la demande ou une fois de temps à autre ? ». Je suis d'avis de le faire une fois de temps à autre.

Pour moi ça ne change pas tant que ça des FS modernes ; il y a la même problématique de répartition en dessous (sur le SSD).

Ca utilise les widgets GTK+, l'ordre des boutons est respecte, la boite de dialogue pour selectionner un fichier est celle de GNOME, les icones changent en fonction du theme GNOME, l'alignement des labels est correcte ect…

Bah, l'utilisation de l'espace et le dimensionnement des éléments sont complètement différents. Et ça se repère tout de suite, je ne l'aime pas en Qt. D'ailleurs, Wireshark est (était, du coup) un des rares programmes GTK+ qui arrive à merder à ce niveau en me mettant des boutons partiellement cachés et des fenêtres in-redimensionnables. Ils ont dû coder ça avec les pieds sans suivre les guidelines GTK. Pas étonnant qu'ils soient passés à Qt…

Pour ceux que cela intéresse, je me suis aussi renseigné pour un boîtier externe USB3 dont le chipset gère lui-même la mise en veille (ASMEdia ASM1051 par exemple). Et ben là aussi c'est le far west et je n'ai pas réussi à trouver.

À noter pour les disques USB : certains permettent de passer des commandes directement au disque avec sdparm (plutôt que hdparm). Et depuis l'USB3, il y a normalement l'“USB Attached SCSI” qui permet également cela, dans le standard et donc normalement utilisable partout. Par contre, je ne sais pas ce qu'il en est du support soft.

Mais justement c'est une vrai debian dès le début. Avec une couche proprio au dessus pour avoir une belle interface web, mais c'est tout.

OK. Mais le support de cette plateforme est-il intégré upstream chez Debian ? C'est plutôt de ça dont je parlais. Car les installations de Debian « ad-hoc » pour les NAS, il y en a plein (voire de simples chroot…). Mais dans la durée, ça ne tient pas, car il n'y a aucun support des versions suivantes.

Il y a potentiellement quelques drivers pas libres tout au plus, j'ai pas été vérifier ça.

Ah, on arrive encore aux merdes classiques… mauvais point pour Synology, qui m'a plutôt impressionné avec ton histoire, quand même.

L'intérêt principal pour moi pour cette machine c'était son prix: à 100€ il est difficile faire quelque chose d'équivalent, qui est toujours utilisable par Madame Michu, et bidouillable par ssh. Certains NAS sont moins cher mais complètement fermés, d'autres sont plus ouverts (Synology, firmware libre) mais plus cher. C'était un bon compromis pour moi.

Oui, je comprends que le rapport utilité/prix est vraiment pas mal. Moi je table sur l'occasion pour avoir des prix corrects ;-)

Mais si je colle l'oreille, j'entends bien un petit "tac" toutes les cinq secondes, et la valeur SMART est incrémentée de un à chaque fois…

Ça me rappelle un disque que j'avais sur un laptop, qui est mort d'un trop grand nombre de (dé)chargements de tête. Ça serait pas un Hitashi ? J'avoue ne pas comprendre comment on peut arriver à mettre une si petite période, mais bon… mystère.

Si tu fais du bittorrent à longueur de journée, cela n'a même plus de sens de chercher à parquer les têtes (puisqu'il va probablement y avoir une demande d'accès dans les 5 mn).

A l'inverse, si tu as bien réglé ton délai avant parquage à une valeur raisonnable de 5 mn, cela ne servira à rien si tu as un process parasite qui accède au disque toutes les 3 mn.

Je ne comprends pas : dans les deux cas, tu as une période d'utilisation inférieure à la période de parquage, et donc les têtes ne se parquent jamais. On aurait un accès toute les demi-heure, avec un parquage de 5 min, ça ferait un nombre de chargements raisonnables. Bref, pas besoin de faire « en fonction » de l'utilisation, une valeur genre 5 minutes irait très bien pour une machine fixe. Le mettre à 30s sur un laptop, pourquoi pas, même si je ne suis pas convaincu de l'effectivité de la résistance aux chocs…

Ce n'est pas si compliqué que cela (enfin c'est relatif je te l'accorde). Si cela t'intéresse tu peux faire une demande sur le forum et j'y répondrai.

Merci, c'est sympa, mais je n'ai pas trop le temps de faire ça pour l'instant. Une autre fois, peut-être.

Merci pour le lien, très intéressant. J'ai déjà vu des points de connexions sur des SSD qui ressemblent trop à un port série ou à un JTAG… je me suis toujours dit qu'il fallait que j'essaye un jour. Mais bon, pas le temps…

195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 12350589

Avec ce genre de valeur qui ne veut rien dire, effectivement, c'est un disque nase qui ne file pas beaucoup d'info intéressante.

Oui enfin le mieux c'est quand même de choisir un NAS qui supporte une vrai Debian dès le début ! Voir par exemple la page de Martin Michlmayr http://www.cyrius.com/debian/

Du coup, ça démystifie beaucoup le truc et ça devient « normal » d'avoir un ordi comme un autre avec une Debian, sur lequel tu peux installer toute la logithèque Debian, même si c'est un armel et qu'il consomme 5W…

smartctl a confirmé mes craintes : il est monté à 56°C !

Bah si t'es effrayé par ça…

194 Temperature_Celsius     0x0022   052   031   000    Old_age   Always       -       62 (Min/Max 12/69)

et son copain à peine moins. Ce sont des Samsung, mais le NAS est placé dans un environnement plutôt fermé.

Rhaa, mais faites du awk correct bon dieu !

sudo smartctl -a $(awk '$2 == "/" && $1 != rootfs { print $1 }' < /proc/mounts) | awk '$2 == "Power_On_Hours" { poh = int($10) } $2 == "Power_Cycle_Count" { pcc = int($10) } END { print poh / pcc }'

mais pas de N Load_Cycle_Count est-ce normal et dans ce cas pourquoi ?

Les données SMART sont assez mal standardisées, et on n'a pas toujours tout. Tu as peut-être d'autres valeurs se rapprochant de cette signification ?

Si je calcule Power_On_Hours/Power_Cycle_Count j'obtiens environ 6.6, puis-je en déduire (en considérant que ma machine utilise tout le temps ce disque) que ma machine est allumée pendant 6 heures et 36 minutes en moyenne ?

Oui, si ton disque est allumé tout le temps quand ta machine l'est.

Le Red a un LCC de… 2.

Au début, j'ai pensé à une valeur erronée, mais en fait c'est peut-être bien vrai. Je viens de voir qu'en fait, le LCC de mon autre NAS n'a pas bougé depuis 48h ; avec les bons réglages, ça marche bien. Mais comme je disais, c'est plutôt les réglages inconscients d'origine qui m'horripilent.

J'imagine que cela dépend de sa sollicitation selon l'agencement du RAID.

Peut-être. Ça voudrait dire que celui à 200 000 est vraiment peu sollicité (paradoxalement), et que ses réglages sont pourris : mieux vaut corriger ça avant qu'il merde vraiment.

Je pense que c'est plutôt une valeur erronée, ça me paraît complètement impossible. Il y a beaucoup de valeurs SMART qui ne veulent rien dur car niveau standardisation, c'est un peu la misère.

Les constructeurs se mettent au 2,5" plus pour la conso d'énergie et la densité (oui, la densité au sens volumique du terme : on fait tenir plus avec des 2,5" que des 3,5" dans un serveur, i.e. il existe des 2To en 2,5" pour 4To en 3,5", alors que la différence de taille (physique) est énorme). Car question fiabilité, les 2,5" qu'ils utilisent ne sont pas ceux du commerce, à part pour les grosses fermes de données où on s'en fout que ça soit fiable à 3,5 ou 2,5" ; c'est des SAS 10k ou 15k, nettement plus endurant. Et aussi, ça permet de rentrer des SSD, qui sont encore plus prisés quand on veut vraiment des perfs.

Ici, sur ce NAS, j'ai dans /etc/default/hdparm :

hdparm_opts="-B254 -S36"

Mais le coeur du problème, c'est trouver ton process qui réveille ton disque. C'est en général pas trop dur à trouver (il faut juste logger tous les accès disques et tu trouveras rapidement le coupable).

Franchement, non, ça n'est pas ça le problème : c'est normal que l'OS veuille écrire des trucs de temps en temps. Par exemple, il sert également de client bittorrent (chose proposée également sur le firmware d'origine, donc il n'y a pas de raison que ça soit « hors spec »). Le truc, c'est que le disque n'a pas à parquer ses têtes toutes les 30s quand c'est du matos fait pour ne pas bouger.

Quant à la « facilité » de trouver les accès disques, j'avais déjà essayé à une époque, ça n'est pas si simple que ça, ou alors je veux bien une doc :-)

Sur un grand nombre de SSD, l'activation du trim (-o discard) entraîne une perte de perf. considérable.

Franchement, se baser sur l'avis d'un mec qui a mis ça dans le wiki… Sans sources, ça me semble exagéré de dire ça. Et ça omet complètement les problèmes d'usure que ça entraîne de ne pas le faire.

Les FS modernes n'ont carrément plus besoin du trim.

WTF ? Soit je n'ai pas compris ce que tu dis, soit tu n'as pas compris le fonctionnement du trim… Bien sûr qu'il sera toujours très utile, et pas que pour les SSD (en virtualisation c'est pratique pour avoir des volumes sparse).

Le trim (Appelé discard sous linux) est trop problématique à plein de niveau.

Les soit-disant « problèmes » évoqués sont juste que discard fait effectivement très bien son boulot : il dit au SSD qu'il peut supprimer ce bloc, et donc oui, forcément, si tu veux le récupérer après un "rm" mal placé, bah tu peux pas, et oui si tu veux être discret sur les zones effacées ou non de ton disque pour des raisons de confidentialité (disque entièrement chiffré), il ne faut pas l'utiliser. Mais désolé, ce sont deux cas d'utilisation très spécifiques et le discard marche très bien pour tout le monde dans 99,9% des cas.

Là où le discard est intéressant, c'est pour la durée de vie du SSD et les perfomances : ça les améliore, car il a moins besoin de refaire de la réécriture interne pour trouver de la place. Perso, je pense que les chiffres classiques d'amplification d'écriture sont souvent beaucoup sous-estimés car ils ne prennent pas en compte une charge classique mais très mauvaise pour les SSD : plein de petites écritures aléatoires. Après, un FS peut mitiger le problème en essayent d'être « gentil » avec le disque à ce niveau, cf par exemple l'option "ssd" (voire ssd_spread pour les contrôleurs vraiment merdiques, i.e. les cartes CF/SD / clé USB, mais faut être un peu maso) de btrfs.

À priori, ce comportement vient d'une « mauvaise utilisation » historique. Avec un terminal comme uRxvt, on peut avoir du vert clair ou foncé gras, avec l'option "+is" (intensityStyles) qui respecte les couleurs théoriques (i.e. on a bien un vert foncé gras avec "\e[1;32mYO" et un vert clair gras avec "\e[1;92mYO").

Ce qui veut dire qu'il faut toujours bien un modem 3G en plus mais il est effectivement intégré au hardware (mais certainement pas au CPU) de manière à pouvoir communiquer avec le CPU quand le système est « éteint ». Ce qui se ferait typiquement sur un laptop.

Si on regarde la datasheet du modem donnée en exemple http://archive.ericsson.net/service/internet/picov/get?DocNo=35/28701-FGB101576&.. il est relié en USB par le port mPCIe. Donc il doit être alimenté pendant que la machine est éteinte, chose « classique » sur des bécanes quand on configure un tout petit peu le BIOS (pour allumer la machine au clavier, par exemple), et doit pouvoir facilement déclencher un allumage par interruption. Bref, c'est juste une intégration ingénieuse de matos on ne peut plus classique.

Bon, dans ce que je comprend du papier d'Intel, le modem 3G c'est quand même un device à part donc je vois pas trop d'où Jim Stone sort que c'est intégré à la puce mais j'ai peut-être raté une référence.

Dans le lien que tu mets (merci au passage), il est clairement indiqué que le lien 3G est effectué par une passerelle externe, reliée en Ethernet à la machine, et que l'AMT passe par celui-ci.

Quand on voit le ton du texte et les images du site d'origine, ça fait clairement conspirationiste à deux francs.

Mais putain arrête de pourrir ce site avec tes réponses vides d'argument, insultantes et basées sur tes pauvres expériences persos. Tu ne réponds même pas aux commentaires intéressants de groumly et René (ou alors tu choisis les parties qui t'arrangent). Moi je n'ai pas envie de te donner que des baffes.

Pour éviter ça, tu peux utiliser les raccourcis clavier, ça va plus vite et ça ne nique pas ta sélection : Ctrl+K puis Backspace puis Clic milieu.