''Garbage Collection'' chez OCZ/Indilinx

Publié le 10/08/2009 à 12:40 par
Imprimer

PC Perspective  a pu tester un OCZ Vertex doté d’un nouveau firmware mis au point par Indilinx introduisant la notion de "background garbage collection". Ce mécanisme vise à redonner au SSD des performances de bon niveau si celles-ci sont dégradées via une réorganisation s’effectuant quand ce dernier n’est pas sollicité par l’utilisateur.


La dégradation des performances des SSD est un sujet que nous avons largement abordé depuis que nous traitons ce sujet, et vous pouvez vous replonger dedans en lisant cette page ainsi que la suivante.

Avec son Barefoot, Indilinx a fait le choix d’un write combining agressif qui lui permet d’obtenir un niveau d’I/O par seconde important dans le cas d’écritures aléatoires. Le write combining permet en effet de transformer des écritures aléatoires au niveau logique (LBA) en écritures séquentielles au niveau physique (Page de mémoire Flash), ceci en réorganisant la table d’allocation entre LBA et Page Flash. Seul problème, si derrière on écrit de nouveau de manière séquentielle sur les mêmes zones logiques, l’utilisation de la même table d’allocation les rendra aléatoire d’un point de vue physique d’où des performances amoindries.

Afin de résoudre ce problème, le SSD peut intégrer un mécanisme visant à réorganiser cette table d’allocation à la volée, ce qui permet de conserver un bon niveau lors d’écritures séquentielles sur une zone précédemment écrite de manière aléatoire. C’est notamment le cas des SSD Samsung et Intel mais là aussi il y’a une contrepartie puisque la surcharge de travail peut faire baisser les écritures aléatoires sur un disque usé – chose qu’Intel a réussi à bien maitrisé à contrario de Samsung.

Probablement pour ne pas avoir le même travers, Indilinx a opté pour une réorganisation à la volée peu agressive et du coup peu efficace pour ce qui est des écritures séquentielles. C’est ici qu’agit la " background garbage collection". Lorsque le SSD n’est pas sollicité par l’utilisateur, le SSD va réorganiser la table d’allocation de manière à la rendre de nouveau linéaire (LBA 0 = Page 0, LBA 1 = Page 1) ce qui est optimal pour les écritures séquentielles.

S’agit-il pour autant d’une solution idéale ? Nous sommes loin d’en être convaincu. Tout d’abord, ce mécanisme ne libère pas les pages Flash au contraire du TRIM, il n’y a donc pas d’impact positif dans le domaine des écritures aléatoires. De plus en agissant de la sorte, ce mécanisme va entrainer une réécriture des données correspondantes. Le nombre de cycle d’écriture des puces Flash étant par nature limité, il n’est pas forcément opportun de générer de nouvelles écritures qui ne seraient pas essentielles. D’ailleurs, en l’absence de TRIM, le SSD s’amusera à réécrire et réorganiser des pages qui correspondent à des fichiers effacés au niveau du système … c’est un peu la double peine.


Au final il nous semble clair que seul le TRIM permet d’apporter une véritable solution à la dégradation des performances d’un SSD. En son absence, le mécanisme de « BGC » mis au point par Indilinx permet certes de retrouver les performances en écriture séquentielles initiales, mais ceci n’est pas sans contrepartie. Cette nouveauté est même complètement contreproductive pour ceux qui bénéficiaient déjà du TRIM via l’utilitaire Wiper, et seuls les possesseurs de Vertex en RAID ou sous MAC / Linux y trouveront un petit intérêt.

Vos réactions

Top articles