Date Tags blabla

… ou “Sandisk collabore avec Canonical pour le support des SSD“.

Oui, c’est fantastique, Canonical collabore avec Sandisk pour améliorer le support des SSD, sauf que :

  • Sandisk ne fait pas vraiment des SSD universellement reconnus pour leurs bonnes performances (si vous en cherchez, tournez-vous plutôt vers Intel, voire Samsung, Memoright ou Mtron, et évidemment FusionIO).
  • Les algorithmes actuels de manipulations de données depuis disque (ex: les jointures dans les DB) sont principalement optimisés pour les HDD, donc en gros, du séquentiel, et aussi un peu de partitionnement et parallélisme. Les SSD sont plus rapides que les HDD en IO séquentielles, donc aucune optimisation majeure à faire de ce côté-là. Les SSD bas de gamme sont très mauvais en partitionnement et parallélisme, donc oui, il y a une optimisation à faire, mais à quoi bon ? Achetez des bons SSD, pas des merdes qui valent pas un HDD.
  • Le support de l’instruction TRIM/ERASE est déjà dans ext4, et pas de l’initiative de Canonical, donc il ne reste pas grand chose à faire pour Canonical (si, activer l’option dans le kernel et mettre ext4 par défaut, waouh, quelle difficulté !).
  • Donc au final, le plus gros du boulot reste à la charge des fabriquants de SSD, pour d’abord, supporter la commande TRIM, ensuite, ne pas utiliser des contrôleurs immondes comme les JMicron JMF6Ox, et enfin d’améliorer leurs FTL, notamment les algorithmes de gestion des logs blocks, mapping d’adresses logiques -> physiques et surtout la garbage collection (éviter les full merges de blocks…). La bonne nouvelle, c’est que les FTL sont complètement fermées et non documentées, donc ça m’étonnerait que Canonical puisse être d’une quelconque aide dans ce domaine (oui, un fabricant qui décrit précisément ce que font ses FTL, ça n’existe pas, et c’est bien là le problème).

Donc, encore une fois (qui a dit comme d’habitude), Canonical n’entreprend rien de réellement utile, et c’est bien dommage…