On peut faire un peut mieux que répéter les shift & masques dans ta fonction hexatochars() :
unsigned int bits = hexa;
if (hexa >= (1<<26)) {
a |= 1<<2;
f = (bits & 0x3f) | 0x80;
bits >>= 6;
}
if (hexa >= (1<<21)) {
a |= 1<<3;
e = (bits & 0x3f) | 0x80;
bits >>= 6;
}
if (hexa >= (1<<16)) {
a |= 1<<4;
d = (bits & 0x3f) | 0x80;
bits >>= 6;
}
if (hexa >= (1<<11)) {
a |= 1<<5;
c = (bits & 0x3f) | 0x80;
bits >>= 6;
}
if (hexa >= (1<<7)) {
a |= (1<<6) | (1<<7);
b = (bits & 0x3f) | 0x80;
bits >>= 6;
}
a |= bits;
J'ai écrit les constantes différemment car je trouve que ça permet de mieux se rendre compte que les intervalles proposés par ce standard encodent 7, 4, 5, 5, 5 et 5 bits chacun, pour un total 31 bits pour un “code point”. En plus, avec le fait qu'on shift toujours de 6 bits, ça m'avait embrouillé sur le calcul, mais en fait ça marche exactement comme ça car chaque octet qui s'ajoute vient rétrécir d'un bit la place qu'on a dans le premier (sauf au premier ajout, où on perd 2 bits car on ne peut pas prendre le préfixe « réservé » 0b10xxxxxx)
OK, excuse pour l'homme de paille, je suis remonté un peu loin dans le thread sans réfléchir. Mais…
2) Le problème est bien plus général que ça, la ne concerne pas que le trim : les firmwares sont buggués, pas assez testés, difficiles à mettre à jour, … C'est un fait. Déplacer vers l'OS résout 99,478% de tout cela.
Je ne suis pas du tout contre le trim. Je suis pour la fonctionnalité passe vers les les OS.
… je t'ai montré en quoi je pensais que ça n'arriverait pas. Donc, en « attendant », le TRIM est indispensable et est quelque chose qui marche plutôt bien. CQFD.
Les problèmes de firmware sont légions en général.
Heu… un problème de firmware sur un SSD d'il y a quatre ans et qui a été le premier (de mémoire) à implémenter le TRIM ? Houa, génial comme argument pour discréditer le TRIM.
Oui, il y a quelques problèmes de firmware parfois, sur plusieurs aspects y compris le TRIM, surtout chez les constructeurs pas consciencieux, mais de la à dire que le TRIM « est trop problématique à plein de niveau », tu exagères beaucoup.
Et quand tu switches de l'un à l'autre, qu'est-ce qu'il se passe ?
Après, je joue l'avocat du diable mais j'aimerais effectivement que ça soit possible. Mais je t'ai exposé mes arguments sur les raisons du peu d'espoir que j'ai…
Crucial n'est pas le seul qui a eu des problèmes. Cela a été de même avec intel et pleins d'autres.
Perso, je m'intéresse un peu aux SSDs, et je n'ai jamais entendu parler de problèmes sur le TRIM. Je veux bien croire qu'il y en a eu à un moment, mais pour que tu conseilles ainsi de se passer de TRIM, là, ça me semble exagéré.
Encore faut-il connaître les touches à appuyer pour joindre le service que l'on souhaite : sur le répondeur de ma banque, il te demande 3 fois de prononcer le nom de l'agence que tu veux joindre avant de tomber sur le « tapez le département sur votre clavier ». Et au menu suivant, alors que tu es toujours dans un environnement bruyant et tu sais très bien que ça va merder, il te redemande 3 fois de prononcer le nom de ton conseiller, avant de te proposer de taper 1 pour avoir l'accueil… Ça fait perdre un temps fou pour rien.
C'est exactement ce genre de conneries que j'espère, qu'on va supprimer. Et arrêter avec les milliers d'implémentation buguées de trim faites par les fabricants. Un SSD vide mais néanmoins pleins c'est quand même bien merdique.
Bah, ce que je te décris c'est la situation avant le TRIM, et le fait d'être « vide mais néanmoins plein » ça ne dépend pas que d'une implémentation « buggée » du trim, mais également de sa non-implémentation. Bref, un trim bien implémenté (comme il l'est sur pas mal de SSD quand même, perso je n'ai jamais eu de problème même si ma base de test est faible) ça ne pose pas de problème.
Ce que je veux c'est du RAW Flash et que l'OS fasse tout.
Moi aussi je voulais ça à une époque et j'ai arrêté de rêver depuis. Ça n'arrivera jamais, car les vendeurs de Flash sont trop contents de vendre 3 fois plus cher leurs puces de Flash en les accompagnant d'un contrôleur pas cher + du soft proprio qui leur permet de segmenter le marché comme ils veulent. Car oui, aujourd'hui les vendeurs de SSD (donc y compris le contrôleur, qui est de toutes façons un ARM dans 99% des cas) sont des fabricants de mémoire. Accessoirement, ça évite les implémentations pourries en soft du wear-leveling (OK, au début tu retrouves des implémentations pourries en « hard », ce qui est… différent).
Et regarde du côté du futur, qui est NVM Express : on reprend les même commandes SCSI et on recommence. Tout ce qu'ils ont changé, c'est le bus en support (du PCIe direct vers le SSD au lieu d'un HBA AHCI qui cause SATA) et quelques suppressions de restrictions sur le nombre de queues, la gestion des interruptions, etc. Bref, c'est juste pour avoir des perfs meilleures, mais le paradigme « je suis juste une suite de secteurs consécutifs sans aucune distinction et aucun contrôle » reste. Remarque, ça aurait demandé un sacré changement niveau soft, qui est assez limité pour NVM Express. Et plus de rapidité, ça se vend bien, alors que plus de longévité… tu veux qu'ils vendent moins de disques, c'est ça !? Tueur de marché !
Sur le SSD :
Pas de table d'allocation
Pas de déplacement de bloc
et donc pas de trim
Tu imagines sur le marché des disques « dumb SSD » avec une étiquette « attention, à n'utiliser qu'avec un OS version X.Y blah blah ». Déjà que le passage aux secteurs 4k a l'air de faire peur à beaucoup de monde, là je n'imagine même pas.
Sur l'OS (Zfs et Btrfs en sont capables) :
Peut chercher lui-même où écrire
Peut faire du CoW lui-même
Peut écrire de façon agglutinée via caching
…
Et sous Windows ? Pas d'implém windows = ça ne se fera pas.
Je veux, pour les SSD, ce que font les compact flash bas de gamme : rien. Juste que les blocs soient exposés à l'OS. Tout le reste doit être géré par l'OS.
Bah, même les CF bas de gamme s'amusent quand même à wear-leveler juste un secteur (ou un peu plus, peut-être) : celui de la FAT du FAT32… Et même s'ils sont très débiles, franchement c'est de la merde à l'utilisation, je ne sais pas comment ils font. Ah si, le contrôleur (qui ne fait pas grand chose) est tout merdique, et c'est parce que de toutes façon ils ne feront même pas d'effort pour enlever cette histoire de gestion de FAT32, juste parce que le prix en R&D doit être à peu près zéro, vu le prix proposé au public.
Actuellement, il faut faire du trim, on ne peut faire autrement. Et c'est merdique à pleins de niveau !
Bah, c'est mieux que rien. Franchement, l'accès raw n'arrivera jamais selon moi, ça changerait trop la sémantique de SCSI, et le jour où on se séparera de SCSI… et donc, le TRIM, c'est la seule solution pour bosser avec ce paradigme. Et elle n'est pas si mal, et conceptuellement propre. Reste aux constructeurs de SSD à faire des implém correctes, mais perso je n'ai pas eu de problème : tu devrais peut-être changer de constructeur.
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…
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…
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.
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.
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 :-)
# Meilleur traduction vers l'utf8
Posté par benoar . En réponse au journal Jouons avec Unicode: Tchars, un Dchars pour Troff. Évalué à 5.
On peut faire un peut mieux que répéter les shift & masques dans ta fonction
hexatochars():J'ai écrit les constantes différemment car je trouve que ça permet de mieux se rendre compte que les intervalles proposés par ce standard encodent 7, 4, 5, 5, 5 et 5 bits chacun, pour un total 31 bits pour un “code point”. En plus, avec le fait qu'on shift toujours de 6 bits, ça m'avait embrouillé sur le calcul, mais en fait ça marche exactement comme ça car chaque octet qui s'ajoute vient rétrécir d'un bit la place qu'on a dans le premier (sauf au premier ajout, où on perd 2 bits car on ne peut pas prendre le préfixe « réservé » 0b10xxxxxx)
[^] # Re: SSD « propres » ?
Posté par benoar . En réponse au journal De l'obsolescence programmée chez Crucial. Évalué à 4.
OK, excuse pour l'homme de paille, je suis remonté un peu loin dans le thread sans réfléchir. Mais…
… je t'ai montré en quoi je pensais que ça n'arriverait pas. Donc, en « attendant », le TRIM est indispensable et est quelque chose qui marche plutôt bien. CQFD.
[^] # Re: SSD « propres » ?
Posté par benoar . En réponse au journal De l'obsolescence programmée chez Crucial. Évalué à 2.
Heu… un problème de firmware sur un SSD d'il y a quatre ans et qui a été le premier (de mémoire) à implémenter le TRIM ? Houa, génial comme argument pour discréditer le TRIM.
Oui, il y a quelques problèmes de firmware parfois, sur plusieurs aspects y compris le TRIM, surtout chez les constructeurs pas consciencieux, mais de la à dire que le TRIM « est trop problématique à plein de niveau », tu exagères beaucoup.
[^] # Re: SSD « propres » ?
Posté par benoar . En réponse au journal De l'obsolescence programmée chez Crucial. Évalué à 3.
Et quand tu switches de l'un à l'autre, qu'est-ce qu'il se passe ?
Après, je joue l'avocat du diable mais j'aimerais effectivement que ça soit possible. Mais je t'ai exposé mes arguments sur les raisons du peu d'espoir que j'ai…
Perso, je m'intéresse un peu aux SSDs, et je n'ai jamais entendu parler de problèmes sur le TRIM. Je veux bien croire qu'il y en a eu à un moment, mais pour que tu conseilles ainsi de se passer de TRIM, là, ça me semble exagéré.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
Super, merci pour la référence. Je m'y mettrais un jour si je trouve un peu de temps.
[^] # Re: Pareil chez les Caribous.
Posté par benoar . En réponse au journal Les serveurs vocaux c'est le mal. Évalué à 2.
Encore faut-il connaître les touches à appuyer pour joindre le service que l'on souhaite : sur le répondeur de ma banque, il te demande 3 fois de prononcer le nom de l'agence que tu veux joindre avant de tomber sur le « tapez le département sur votre clavier ». Et au menu suivant, alors que tu es toujours dans un environnement bruyant et tu sais très bien que ça va merder, il te redemande 3 fois de prononcer le nom de ton conseiller, avant de te proposer de taper 1 pour avoir l'accueil… Ça fait perdre un temps fou pour rien.
[^] # Re: SSD « propres » ?
Posté par benoar . En réponse au journal De l'obsolescence programmée chez Crucial. Évalué à 2.
Bah, ce que je te décris c'est la situation avant le TRIM, et le fait d'être « vide mais néanmoins plein » ça ne dépend pas que d'une implémentation « buggée » du trim, mais également de sa non-implémentation. Bref, un trim bien implémenté (comme il l'est sur pas mal de SSD quand même, perso je n'ai jamais eu de problème même si ma base de test est faible) ça ne pose pas de problème.
Moi aussi je voulais ça à une époque et j'ai arrêté de rêver depuis. Ça n'arrivera jamais, car les vendeurs de Flash sont trop contents de vendre 3 fois plus cher leurs puces de Flash en les accompagnant d'un contrôleur pas cher + du soft proprio qui leur permet de segmenter le marché comme ils veulent. Car oui, aujourd'hui les vendeurs de SSD (donc y compris le contrôleur, qui est de toutes façons un ARM dans 99% des cas) sont des fabricants de mémoire. Accessoirement, ça évite les implémentations pourries en soft du wear-leveling (OK, au début tu retrouves des implémentations pourries en « hard », ce qui est… différent).
Et regarde du côté du futur, qui est NVM Express : on reprend les même commandes SCSI et on recommence. Tout ce qu'ils ont changé, c'est le bus en support (du PCIe direct vers le SSD au lieu d'un HBA AHCI qui cause SATA) et quelques suppressions de restrictions sur le nombre de queues, la gestion des interruptions, etc. Bref, c'est juste pour avoir des perfs meilleures, mais le paradigme « je suis juste une suite de secteurs consécutifs sans aucune distinction et aucun contrôle » reste. Remarque, ça aurait demandé un sacré changement niveau soft, qui est assez limité pour NVM Express. Et plus de rapidité, ça se vend bien, alors que plus de longévité… tu veux qu'ils vendent moins de disques, c'est ça !? Tueur de marché !
Tu imagines sur le marché des disques « dumb SSD » avec une étiquette « attention, à n'utiliser qu'avec un OS version X.Y blah blah ». Déjà que le passage aux secteurs 4k a l'air de faire peur à beaucoup de monde, là je n'imagine même pas.
Et sous Windows ? Pas d'implém windows = ça ne se fera pas.
Bah, même les CF bas de gamme s'amusent quand même à wear-leveler juste un secteur (ou un peu plus, peut-être) : celui de la FAT du FAT32… Et même s'ils sont très débiles, franchement c'est de la merde à l'utilisation, je ne sais pas comment ils font. Ah si, le contrôleur (qui ne fait pas grand chose) est tout merdique, et c'est parce que de toutes façon ils ne feront même pas d'effort pour enlever cette histoire de gestion de FAT32, juste parce que le prix en R&D doit être à peu près zéro, vu le prix proposé au public.
Bah, c'est mieux que rien. Franchement, l'accès raw n'arrivera jamais selon moi, ça changerait trop la sémantique de SCSI, et le jour où on se séparera de SCSI… et donc, le TRIM, c'est la seule solution pour bosser avec ce paradigme. Et elle n'est pas si mal, et conceptuellement propre. Reste aux constructeurs de SSD à faire des implém correctes, mais perso je n'ai pas eu de problème : tu devrais peut-être changer de constructeur.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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.
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)
Oui, mais ça peut parfois être utile pour savoir qu'il ne s'est pas arrêté, peut-être.
Oui. Si tu (on ?) pouvais remonter remonter ça upstream avec des bugreports sympas, afin de trouver une solution à ça, ça serait génial… :-)
[^] # Re: SSD « propres » ?
Posté par benoar . En réponse au journal De l'obsolescence programmée chez Crucial. Évalué à 3.
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.
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.
Je ne comprends pas ce que tu veux dire… tu parles d'un « reset » qui serait ton fstrim, mais fait régulièrement / automatiquement ?
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).
[^] # Re: Pas les premiers à changer et pas les derniers
Posté par benoar . En réponse à la dépêche Wireshark passe à Qt. Évalué à 3.
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…
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 3.
À noter pour les disques USB : certains permettent de passer des commandes directement au disque avec
sdparm(plutôt quehdparm). 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.[^] # Re: Le problème n'est pas nouveau
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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.
Ah, on arrive encore aux merdes classiques… mauvais point pour Synology, qui m'a plutôt impressionné avec ton histoire, quand même.
Oui, je comprends que le rapport utilité/prix est vraiment pas mal. Moi je table sur l'occasion pour avoir des prix corrects ;-)
[^] # Re: Moi aussi je peux jouer ?
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 3.
Ç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.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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…
Merci, c'est sympa, mais je n'ai pas trop le temps de faire ça pour l'instant. Une autre fois, peut-être.
[^] # Re: Rien à voir mais tant qu'on est là à parler de disquer dur
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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…
[^] # Re: Moi aussi je veux jouer
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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.
[^] # Re: Le problème n'est pas nouveau
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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…
[^] # Re: Disques externes (ou tout est relatif)
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
Bah si t'es effrayé par ça…
et son copain à peine moins. Ce sont des Samsung, mais le NAS est placé dans un environnement plutôt fermé.
[^] # Re: Moi aussi je veux jouer
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 1.
Rhaa, mais faites du awk correct bon dieu !
[^] # Re: Moi aussi je veux jouer
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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 ?
Oui, si ton disque est allumé tout le temps quand ta machine l'est.
[^] # Re: Selon l'utilisation...
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 1.
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.
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.
[^] # Re: Moi aussi je peux jouer ?
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 3.
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.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
Ici, sur ce NAS, j'ai dans
/etc/default/hdparm:[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par benoar . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
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 :-)