• [^] # Re: SSD « propres » ?

    Posté par . En réponse au journal De l'obsolescence programmée chez Crucial. Évalué à 2.

    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.