disque SSD et fichiers temporaires

patpro ~ patrick proniewski

01/11/2011 à 01:32

In article <1ka11f7.imrmk915hkxmiN%,
(Gilles Aurejac) wrote:

- ce système interne au SSD de wear-leveling est complémenté au niveau
OS par une fonction qui s'appelle TRIM mais qui n'est qu'un complément.

Le trim n'a rien à voir avec le wear leveling. Même pas de loin, et n'a
aucune vocation en terme de durée de vie du SSD.
C'est un simple "garbage collector" de cellules. Cette commande nettoie
par anticipation les cellules qui ne sont plus allouées à des données,
de sorte qu'elles sont immédiatement prêtes à l'usage quand tu souhaites
écrire dessus.
Quand tu ne disposes pas de la commande trim, le controleur de disque
doit effacer la cellule avant d'écrire dessus, ce qui fait perdre des
performances quand le disque a été suffisamment utilisé pour que la
majorité de ses cellules aient été écrites une fois.
Avec la commande trim, ce nettoyage est fait à l'avance, ce qui permet
de maintenir un niveau de performance constant dans le temps.

Si tu imagines par exemple l'utilisation d'un SSD comme cache dans un
pool ZFS, la fonction trim est totalement inutile. La vocation d'un
disque de cache étant d'être plein au raz-bord en permanence, il n'y a
jamais aucune action de nettoyage à faire en prévision d'une écriture
ultérieure. Le nettoyage doit avoir lieu immédiatement entre
l'effacement des données et leur remplacement par d'autres et ces trois
actions s'enchainent aussi vite que le controleur peut les réaliser.

(Et moi je veux un ioDrive Octal, le reste c'est pour les fillettes.)

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133

gilles

01/11/2011 à 04:47

patpro ~ patrick proniewski wrote:

In article <1ka11f7.imrmk915hkxmiN%,
(Gilles Aurejac) wrote:

> - ce système interne au SSD de wear-leveling est complémenté au niveau
> OS par une fonction qui s'appelle TRIM mais qui n'est qu'un complément.

Le trim n'a rien à voir avec le wear leveling. Même pas de loin, et n'a
aucune vocation en terme de durée de vie du SSD.
C'est un simple "garbage collector" de cellules. Cette commande nettoie
par anticipation les cellules qui ne sont plus allouées à des données,
de sorte qu'elles sont immédiatement prêtes à l'usage quand tu souhaites
écrire dessus.
Quand tu ne disposes pas de la commande trim, le controleur de disque
doit effacer la cellule avant d'écrire dessus, ce qui fait perdre des
performances quand le disque a été suffisamment utilisé pour que la
majorité de ses cellules aient été écrites une fois.
Avec la commande trim, ce nettoyage est fait à l'avance, ce qui permet
de maintenir un niveau de performance constant dans le temps.

Bon je vais peut être enfoncer pour toi des portes ouvertes... j'essaie
d'expliquer..

Le trim n'est pas du wear leveling mais tu noteras que je n'ai jamais
dit que ça en était, j'ai dit que ça *complémentait* le wear leveling

nuance...

Et je ne trouve pas ça précis de dire que le trim "nettoie les cellules"
Le trim est un marquage par l'OS de l'espace libéré par l'effacement des
fichiers, et ce n'est que ça.

L'opération dont tu parles (nettoyer les cellules) c'est la "garbage
collection" qui le fait, et ça se passe indépendamment du fait que le
trim soit activé ou non dans l'OS.
les SSD actuels ont tous un garbage collector au niveau de leur
firmware.

un SSD est constitué de blocs (128 ou 512 Ko) eux mêmes consitutés de
pages (4k) elles-mêmes consitutuées de cellules (une cellule = 1 bit en
SLC, 2 ou 3 bits en MLC).
Les SSD ne savent écrire les données que par pages entieres (4Ko) . Et
ils ne savent pas réécrire sur une page où il y a eu des données, il
faut la réeffacer avant d'écrire.

Or l'effacement d'une page seule est impossible.

Un effacement ne peut se faire que par bloc entier (128k) : dès qu'on
n'a plus de page préalablement "effacée" dans un bloc, le SSD est obligé
de faire une opération de "garbage collection"
il faut lire les pages valides du bloc, les écrire en cache, effacer le
bloc, et réécrire les pages valides depuis le cache, + la ou les
nouvelles pages à écrire, en les réorganisant au passage.

Le trim n'est pas en soi *un* garbage collector.

Le garbage collector fonctionne toujours, trim ou pas trim, et agit en
tache de fond ou lorsqu'il y a une écriture à faire.

Toute la nuance est lors des effacements !

- Sans le trim, le système de fichiers croit qu'il a affaire à un disque
à plateaux, et effacer un fichier revient uniquement à éffacer son
entrée dans le btree.
le SSD ne sait pas que le fichier a été effacé et ceci empêche de
libérer les blocs (noter que l'effacement de données à zero sur un SSD,
c'est pire : ça revient à écrire des données - le zero pour une mémoire
flash c'est FF pas zero - donc à perdre des cycles d'écriture)
Le garbage collector est incapable de savoir que des pages sont libérées
par le système d'exploitation, et donc, perd son temps (et de la place)
à lire des pages contenant des données qui ont été effacées, et à les
réécrire dans le bloc, alors que c'est inutile..

- Avec le trim, le SSD est informé que les données effacées sont libres.
Du coup le garbage collector est informé que les pages sont libérées par
l'OS suite à leur effacement, et non seulement il peut les ignorer (il
n'y a plus besoin de les lire, mettre en cache, et réécrire lors d'une
opération d'effacement de bloc) mais en plus, leur place peut évidemment
être récupérée lors des opérations de garbage collection pour écrire
d'autres pages situées dans le cache.

Evidemment (et j'enfonce peut-être des portes ouvertes) avec le TRIM,
aucune récupération de fichier effacé possible ! data rescue = 0...

En soi le TRIM a pour but, si il y a assez d'espace libre au niveau du
système de fichiers, de rendre plus efficace le garbage collector en
l'informant des fichiers effacés. ceci limite très fortement
l'amplification d'écriture et, partant, l'usure des cellules du SSD.

Tout ça participe bel et bien à la durée de vie du SSD...

Si tu imagines par exemple l'utilisation d'un SSD comme cache dans un
pool ZFS, la fonction trim est totalement inutile. La vocation d'un
disque de cache étant d'être plein au raz-bord en permanence, il n'y a
jamais aucune action de nettoyage à faire en prévision d'une écriture
ultérieure. Le nettoyage doit avoir lieu immédiatement entre
l'effacement des données et leur remplacement par d'autres et ces trois
actions s'enchainent aussi vite que le controleur peut les réaliser.

ah ben voilà un exemple qui va me servir tous les jours :-)

et puis en même temps : s'il n'y a pas d'espace libre, on s'en fout un
peu du trim, puisque qu'il n'y en pratique pas d'effacement, mais des
écritures, déjà prises en charge nativement par le garbage collector.

(Et moi je veux un ioDrive Octal, le reste c'est pour les fillettes.)

c'est perso, mais je préfère un "tiens" que deux "tu l'auras" :-)

Et, heu, on est sur un forum mac, là :-) tu veux l'utiliser dans quoi le
ioDrive octal ? dans un Xserve ? =-)

patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:

In article <1ka11f7.imrmk915hkxmiN%gilles@alussinan.org>,
gilles@alussinan.org (Gilles Aurejac) wrote:

> - ce système interne au SSD de wear-leveling est complémenté au niveau
> OS par une fonction qui s'appelle TRIM mais qui n'est qu'un complément.

Le trim n'a rien à voir avec le wear leveling. Même pas de loin, et n'a
aucune vocation en terme de durée de vie du SSD.
C'est un simple "garbage collector" de cellules. Cette commande nettoie
par anticipation les cellules qui ne sont plus allouées à des données,
de sorte qu'elles sont immédiatement prêtes à l'usage quand tu souhaites
écrire dessus.
Quand tu ne disposes pas de la commande trim, le controleur de disque
doit effacer la cellule avant d'écrire dessus, ce qui fait perdre des
performances quand le disque a été suffisamment utilisé pour que la
majorité de ses cellules aient été écrites une fois.
Avec la commande trim, ce nettoyage est fait à l'avance, ce qui permet
de maintenir un niveau de performance constant dans le temps.

Bon je vais peut être enfoncer pour toi des portes ouvertes... j'essaie
d'expliquer..

Le trim n'est pas du wear leveling mais tu noteras que je n'ai jamais
dit que ça en était, j'ai dit que ça *complémentait* le wear leveling

nuance...

Et je ne trouve pas ça précis de dire que le trim "nettoie les cellules"
Le trim est un marquage par l'OS de l'espace libéré par l'effacement des
fichiers, et ce n'est que ça.

L'opération dont tu parles (nettoyer les cellules) c'est la "garbage
collection" qui le fait, et ça se passe indépendamment du fait que le
trim soit activé ou non dans l'OS.
les SSD actuels ont tous un garbage collector au niveau de leur
firmware.

un SSD est constitué de blocs (128 ou 512 Ko) eux mêmes consitutés de
pages (4k) elles-mêmes consitutuées de cellules (une cellule = 1 bit en
SLC, 2 ou 3 bits en MLC).
Les SSD ne savent écrire les données que par pages entieres (4Ko) . Et
ils ne savent pas réécrire sur une page où il y a eu des données, il
faut la réeffacer avant d'écrire.

Or l'effacement d'une page seule est impossible.

Un effacement ne peut se faire que par bloc entier (128k) : dès qu'on
n'a plus de page préalablement "effacée" dans un bloc, le SSD est obligé
de faire une opération de "garbage collection"
il faut lire les pages valides du bloc, les écrire en cache, effacer le
bloc, et réécrire les pages valides depuis le cache, + la ou les
nouvelles pages à écrire, en les réorganisant au passage.

Le trim n'est pas en soi *un* garbage collector.

Le garbage collector fonctionne toujours, trim ou pas trim, et agit en
tache de fond ou lorsqu'il y a une écriture à faire.

Toute la nuance est lors des effacements !

- Sans le trim, le système de fichiers croit qu'il a affaire à un disque
à plateaux, et effacer un fichier revient uniquement à éffacer son
entrée dans le btree.
le SSD ne sait pas que le fichier a été effacé et ceci empêche de
libérer les blocs (noter que l'effacement de données à zero sur un SSD,
c'est pire : ça revient à écrire des données - le zero pour une mémoire
flash c'est FF pas zero - donc à perdre des cycles d'écriture)
Le garbage collector est incapable de savoir que des pages sont libérées
par le système d'exploitation, et donc, perd son temps (et de la place)
à lire des pages contenant des données qui ont été effacées, et à les
réécrire dans le bloc, alors que c'est inutile..

- Avec le trim, le SSD est informé que les données effacées sont libres.
Du coup le garbage collector est informé que les pages sont libérées par
l'OS suite à leur effacement, et non seulement il peut les ignorer (il
n'y a plus besoin de les lire, mettre en cache, et réécrire lors d'une
opération d'effacement de bloc) mais en plus, leur place peut évidemment
être récupérée lors des opérations de garbage collection pour écrire
d'autres pages situées dans le cache.

Evidemment (et j'enfonce peut-être des portes ouvertes) avec le TRIM,
aucune récupération de fichier effacé possible ! data rescue = 0...

En soi le TRIM a pour but, si il y a assez d'espace libre au niveau du
système de fichiers, de rendre plus efficace le garbage collector en
l'informant des fichiers effacés. ceci limite très fortement
l'amplification d'écriture et, partant, l'usure des cellules du SSD.

Tout ça participe bel et bien à la durée de vie du SSD...

Si tu imagines par exemple l'utilisation d'un SSD comme cache dans un
pool ZFS, la fonction trim est totalement inutile. La vocation d'un
disque de cache étant d'être plein au raz-bord en permanence, il n'y a
jamais aucune action de nettoyage à faire en prévision d'une écriture
ultérieure. Le nettoyage doit avoir lieu immédiatement entre
l'effacement des données et leur remplacement par d'autres et ces trois
actions s'enchainent aussi vite que le controleur peut les réaliser.

ah ben voilà un exemple qui va me servir tous les jours :-)

et puis en même temps : s'il n'y a pas d'espace libre, on s'en fout un
peu du trim, puisque qu'il n'y en pratique pas d'effacement, mais des
écritures, déjà prises en charge nativement par le garbage collector.

(Et moi je veux un ioDrive Octal, le reste c'est pour les fillettes.)

c'est perso, mais je préfère un "tiens" que deux "tu l'auras" :-)

Et, heu, on est sur un forum mac, là :-) tu veux l'utiliser dans quoi le
ioDrive octal ? dans un Xserve ? =-)

Vous avez filtré cet utilisateur ! Consultez son message

patpro ~ patrick proniewski wrote:

In article <1ka11f7.imrmk915hkxmiN%,
(Gilles Aurejac) wrote:

> - ce système interne au SSD de wear-leveling est complémenté au niveau
> OS par une fonction qui s'appelle TRIM mais qui n'est qu'un complément.

Le trim n'a rien à voir avec le wear leveling. Même pas de loin, et n'a
aucune vocation en terme de durée de vie du SSD.
C'est un simple "garbage collector" de cellules. Cette commande nettoie
par anticipation les cellules qui ne sont plus allouées à des données,
de sorte qu'elles sont immédiatement prêtes à l'usage quand tu souhaites
écrire dessus.
Quand tu ne disposes pas de la commande trim, le controleur de disque
doit effacer la cellule avant d'écrire dessus, ce qui fait perdre des
performances quand le disque a été suffisamment utilisé pour que la
majorité de ses cellules aient été écrites une fois.
Avec la commande trim, ce nettoyage est fait à l'avance, ce qui permet
de maintenir un niveau de performance constant dans le temps.

Bon je vais peut être enfoncer pour toi des portes ouvertes... j'essaie
d'expliquer..

Le trim n'est pas du wear leveling mais tu noteras que je n'ai jamais
dit que ça en était, j'ai dit que ça *complémentait* le wear leveling

nuance...

Et je ne trouve pas ça précis de dire que le trim "nettoie les cellules"
Le trim est un marquage par l'OS de l'espace libéré par l'effacement des
fichiers, et ce n'est que ça.

L'opération dont tu parles (nettoyer les cellules) c'est la "garbage
collection" qui le fait, et ça se passe indépendamment du fait que le
trim soit activé ou non dans l'OS.
les SSD actuels ont tous un garbage collector au niveau de leur
firmware.

un SSD est constitué de blocs (128 ou 512 Ko) eux mêmes consitutés de
pages (4k) elles-mêmes consitutuées de cellules (une cellule = 1 bit en
SLC, 2 ou 3 bits en MLC).
Les SSD ne savent écrire les données que par pages entieres (4Ko) . Et
ils ne savent pas réécrire sur une page où il y a eu des données, il
faut la réeffacer avant d'écrire.

Or l'effacement d'une page seule est impossible.

Un effacement ne peut se faire que par bloc entier (128k) : dès qu'on
n'a plus de page préalablement "effacée" dans un bloc, le SSD est obligé
de faire une opération de "garbage collection"
il faut lire les pages valides du bloc, les écrire en cache, effacer le
bloc, et réécrire les pages valides depuis le cache, + la ou les
nouvelles pages à écrire, en les réorganisant au passage.

Le trim n'est pas en soi *un* garbage collector.

Le garbage collector fonctionne toujours, trim ou pas trim, et agit en
tache de fond ou lorsqu'il y a une écriture à faire.

Toute la nuance est lors des effacements !

- Sans le trim, le système de fichiers croit qu'il a affaire à un disque
à plateaux, et effacer un fichier revient uniquement à éffacer son
entrée dans le btree.
le SSD ne sait pas que le fichier a été effacé et ceci empêche de
libérer les blocs (noter que l'effacement de données à zero sur un SSD,
c'est pire : ça revient à écrire des données - le zero pour une mémoire
flash c'est FF pas zero - donc à perdre des cycles d'écriture)
Le garbage collector est incapable de savoir que des pages sont libérées
par le système d'exploitation, et donc, perd son temps (et de la place)
à lire des pages contenant des données qui ont été effacées, et à les
réécrire dans le bloc, alors que c'est inutile..

- Avec le trim, le SSD est informé que les données effacées sont libres.
Du coup le garbage collector est informé que les pages sont libérées par
l'OS suite à leur effacement, et non seulement il peut les ignorer (il
n'y a plus besoin de les lire, mettre en cache, et réécrire lors d'une
opération d'effacement de bloc) mais en plus, leur place peut évidemment
être récupérée lors des opérations de garbage collection pour écrire
d'autres pages situées dans le cache.

Evidemment (et j'enfonce peut-être des portes ouvertes) avec le TRIM,
aucune récupération de fichier effacé possible ! data rescue = 0...

En soi le TRIM a pour but, si il y a assez d'espace libre au niveau du
système de fichiers, de rendre plus efficace le garbage collector en
l'informant des fichiers effacés. ceci limite très fortement
l'amplification d'écriture et, partant, l'usure des cellules du SSD.

Tout ça participe bel et bien à la durée de vie du SSD...

Si tu imagines par exemple l'utilisation d'un SSD comme cache dans un
pool ZFS, la fonction trim est totalement inutile. La vocation d'un
disque de cache étant d'être plein au raz-bord en permanence, il n'y a
jamais aucune action de nettoyage à faire en prévision d'une écriture
ultérieure. Le nettoyage doit avoir lieu immédiatement entre
l'effacement des données et leur remplacement par d'autres et ces trois
actions s'enchainent aussi vite que le controleur peut les réaliser.

ah ben voilà un exemple qui va me servir tous les jours :-)

et puis en même temps : s'il n'y a pas d'espace libre, on s'en fout un
peu du trim, puisque qu'il n'y en pratique pas d'effacement, mais des
écritures, déjà prises en charge nativement par le garbage collector.

(Et moi je veux un ioDrive Octal, le reste c'est pour les fillettes.)

c'est perso, mais je préfère un "tiens" que deux "tu l'auras" :-)

Et, heu, on est sur un forum mac, là :-) tu veux l'utiliser dans quoi le
ioDrive octal ? dans un Xserve ? =-)

La Bete des Vosges (Francis Chartier)

01/11/2011 à 09:47

Le Tue, 01 Nov 2011 00:49:54 +0100, Gilles Aurejac a écrit :

J'ai eu les pires problèmes avec des SSD OCZ (incompatibilité totale
avec bootcamp, pertes de données en SATA-III ou même en SATA-II pour les
vertex II), et de toutes façons ces SSD ont des taux de retour annuels
entre 5 et 7 %.

A noter également qu'en activant la fonction Trim sur des SSD OCZ, pas
mal d'utilisateurs subissent des ralentissements temporaires.
J'ai fait le test sous 10.6.8 et 10.7.1 : avec Trim activé pour un Vertex
III des gels temporaires de 15 à 20 secondes plusieurs fois par heure.
Une fois le Trim désactivé, tout est rentré dans l'ordre.

Je pense d'ailleurs remplacer cet OCZ par un Intel avant d'être
réellement planté. :)

Par contre, une fois le SSD adopté pour le disque système, c'est
difficile de revenir à un système sur disque dur traditionnel, on
s'habitue vite à la vitesse de boot et de chargement des applications...

--
La Bête des Vosges

patpro ~ patrick proniewski

01/11/2011 à 09:55

In article <1ka16kj.1gisdcl1nugu76N%,
(Gilles Aurejac) wrote:

Tout ça participe bel et bien à la durée de vie du SSD...

hmmm effectivement.

> Si tu imagines par exemple l'utilisation d'un SSD comme cache dans un
> pool ZFS, la fonction trim est totalement inutile. La vocation d'un
> disque de cache étant d'être plein au raz-bord en permanence, il n'y a
> jamais aucune action de nettoyage à faire en prévision d'une écriture
> ultérieure. Le nettoyage doit avoir lieu immédiatement entre
> l'effacement des données et leur remplacement par d'autres et ces trois
> actions s'enchainent aussi vite que le controleur peut les réaliser.

ah ben voilà un exemple qui va me servir tous les jours :-)

ha ben oui, y'a des tas de gens qui utilisent ZFS. Surtout en
entreprise, certes. Mais finalement c'est là que tu rencontres des gros
serveurs plein de disques, et dont les performances sont partagées entre
des milliers d'utilisateurs. C'est bien là qu'avoir le max d'IO/s est
important., pas pour lancer Word.

> (Et moi je veux un ioDrive Octal, le reste c'est pour les fillettes.)

c'est perso, mais je préfère un "tiens" que deux "tu l'auras" :-)

ha ben celui là "je l'aura pas", c'est sûr. Il coute juste la moitié de
mon appartement.

Et, heu, on est sur un forum mac, là :-) tu veux l'utiliser dans quoi le
ioDrive octal ? dans un Xserve ? =-)

Dans un Mac Pro, les autres machines c'est pour les fillettes. (ou alors
dans mon serveur supermicro, sous FreeBSD avec ZFS, mais j'arrive déjà
pas à utiliser toute la RAM alors...)

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133

gilles

01/11/2011 à 14:12

patpro ~ patrick proniewski wrote:

ha ben oui, y'a des tas de gens qui utilisent ZFS. Surtout en
entreprise, certes. Mais finalement c'est là que tu rencontres des gros
serveurs plein de disques, et dont les performances sont partagées entre
des milliers d'utilisateurs. C'est bien là qu'avoir le max d'IO/s est
important., pas pour lancer Word.

en entreprise, oui, mais en province sur un marché de petites pme
quasiment toutes de moins de 50 salariés, pas tous les jours !

ha ben celui là "je l'aura pas", c'est sûr. Il coute juste la moitié de
mon appartement.

ça fait un peu cher pour lancer MacSoup :-)

Dans un Mac Pro, les autres machines c'est pour les fillettes.

Désolé c'était un peu de la provoc, sachant les rumeurs qui circulent
ces jours-ci sur la disparition des mac pro, qui semble terriblement
dans la logique actuelle, et qui ferait pas mon bonheur...

(ou alors
dans mon serveur supermicro, sous FreeBSD avec ZFS, mais j'arrive déjà
pas à utiliser toute la RAM alors...)

bah, tu peux la recycler dans un mac pro...

gilles

01/11/2011 à 14:12

La Bete des Vosges (Francis Chartier)
wrote:

Le Tue, 01 Nov 2011 00:49:54 +0100, Gilles Aurejac a écrit :

> J'ai eu les pires problèmes avec des SSD OCZ (incompatibilité totale
> avec bootcamp, pertes de données en SATA-III ou même en SATA-II pour les
> vertex II), et de toutes façons ces SSD ont des taux de retour annuels
> entre 5 et 7 %.

A noter également qu'en activant la fonction Trim sur des SSD OCZ, pas
mal d'utilisateurs subissent des ralentissements temporaires.

c'est un peu normal quand on active le trim sur un disque qui a été pas
mal utilisé auparavant sans trim : il y a plein de pages vidées par le
système de fichiers, dont le SSD n'était pas au courant.
le fait d'activer le trim va "libérer" du jour au lendemain toutes ces
pages pour le garbage collector, qui, du coup, se retrouve avec plein de
travail à faire...

normalement, ça se stabilise.

Après, pour les 2 SSD vertex que j'ai essayé, dès qu'ils étaient sur une
machine qui les poussait un peu dans leur retranchements, j'avais des
milliers d'erreurs CRC et la roue qui tournait.

je crois que les OCZ et leur timings poussés à bout et leur optimisation
"pour les benchs" ne sont vraiment pas bien adaptés aux nappes SATA pas
tout à fait dans les normes des macbook pro, par exemple.

J'ai fait le test sous 10.6.8 et 10.7.1 : avec Trim activé pour un Vertex
III des gels temporaires de 15 à 20 secondes plusieurs fois par heure.
Une fois le Trim désactivé, tout est rentré dans l'ordre.

Normalement les fonctions trim sont envoyées par lot, et c'est vrai
qu'elles provoquent des interruptions.

Mais si une interruption de quelques dizaines de milisecondes est
normale (acceptable pour un ordi de bureau, pas pour un serveur), 15 à
20 secondes c'est absolument anormal...

OCZ sort tellement de modèles et ils font tellement peu de R&D par
rapport à samsung et intel que c'est impossible qu'ils testent tous
leurs modèles dans tous les Mac.
Ils ont mis des mois à ne serait-ce qu'identifier les incompatibilités
complètes entre leurs disques et Bootcamp sur certaines machines, et les
erreurs CRC.

Tu pourrais peut-être télécharger smart utility et regarder si il y a
des erreurs CRC...

Je pense d'ailleurs remplacer cet OCZ par un Intel avant d'être
réellement planté. :)

Ben franchement, j'hésite plus jamais moi : entre les quelques petits
chouillats de performance en plus des OCZ, et la tranquilité d'esprit
d'un intel (qui reste un monstre de performances par rapport à un HD
classique), j'hésite pas...

j'ai recyclé les 2 OCZ que j'ai eu dans des machines en SATA-I, comme
ça, je suis tranquille...

Par contre, une fois le SSD adopté pour le disque système, c'est
difficile de revenir à un système sur disque dur traditionnel, on
s'habitue vite à la vitesse de boot et de chargement des applications...

ah ça... c'est dur de convaincre les utilisateurs que pour le même prix,
un baril de SSD vaut mieux que plusieurs barils de processeurs, mais une
fois que c'est fait, comme tu dis plus personne ne revient en arrière.

La Bete des Vosges (Francis Chartier) <francis@bete-des-vosges.org>
wrote:

Le Tue, 01 Nov 2011 00:49:54 +0100, Gilles Aurejac a écrit :

> J'ai eu les pires problèmes avec des SSD OCZ (incompatibilité totale
> avec bootcamp, pertes de données en SATA-III ou même en SATA-II pour les
> vertex II), et de toutes façons ces SSD ont des taux de retour annuels
> entre 5 et 7 %.

A noter également qu'en activant la fonction Trim sur des SSD OCZ, pas
mal d'utilisateurs subissent des ralentissements temporaires.

c'est un peu normal quand on active le trim sur un disque qui a été pas
mal utilisé auparavant sans trim : il y a plein de pages vidées par le
système de fichiers, dont le SSD n'était pas au courant.
le fait d'activer le trim va "libérer" du jour au lendemain toutes ces
pages pour le garbage collector, qui, du coup, se retrouve avec plein de
travail à faire...

normalement, ça se stabilise.

Après, pour les 2 SSD vertex que j'ai essayé, dès qu'ils étaient sur une
machine qui les poussait un peu dans leur retranchements, j'avais des
milliers d'erreurs CRC et la roue qui tournait.

je crois que les OCZ et leur timings poussés à bout et leur optimisation
"pour les benchs" ne sont vraiment pas bien adaptés aux nappes SATA pas
tout à fait dans les normes des macbook pro, par exemple.

J'ai fait le test sous 10.6.8 et 10.7.1 : avec Trim activé pour un Vertex
III des gels temporaires de 15 à 20 secondes plusieurs fois par heure.
Une fois le Trim désactivé, tout est rentré dans l'ordre.

Normalement les fonctions trim sont envoyées par lot, et c'est vrai
qu'elles provoquent des interruptions.

Mais si une interruption de quelques dizaines de milisecondes est
normale (acceptable pour un ordi de bureau, pas pour un serveur), 15 à
20 secondes c'est absolument anormal...

OCZ sort tellement de modèles et ils font tellement peu de R&D par
rapport à samsung et intel que c'est impossible qu'ils testent tous
leurs modèles dans tous les Mac.
Ils ont mis des mois à ne serait-ce qu'identifier les incompatibilités
complètes entre leurs disques et Bootcamp sur certaines machines, et les
erreurs CRC.

Tu pourrais peut-être télécharger smart utility et regarder si il y a
des erreurs CRC...

Je pense d'ailleurs remplacer cet OCZ par un Intel avant d'être
réellement planté. :)

Ben franchement, j'hésite plus jamais moi : entre les quelques petits
chouillats de performance en plus des OCZ, et la tranquilité d'esprit
d'un intel (qui reste un monstre de performances par rapport à un HD
classique), j'hésite pas...

j'ai recyclé les 2 OCZ que j'ai eu dans des machines en SATA-I, comme
ça, je suis tranquille...

Par contre, une fois le SSD adopté pour le disque système, c'est
difficile de revenir à un système sur disque dur traditionnel, on
s'habitue vite à la vitesse de boot et de chargement des applications...

ah ça... c'est dur de convaincre les utilisateurs que pour le même prix,
un baril de SSD vaut mieux que plusieurs barils de processeurs, mais une
fois que c'est fait, comme tu dis plus personne ne revient en arrière.

Vous avez filtré cet utilisateur ! Consultez son message

La Bete des Vosges (Francis Chartier)
wrote:

Le Tue, 01 Nov 2011 00:49:54 +0100, Gilles Aurejac a écrit :

> J'ai eu les pires problèmes avec des SSD OCZ (incompatibilité totale
> avec bootcamp, pertes de données en SATA-III ou même en SATA-II pour les
> vertex II), et de toutes façons ces SSD ont des taux de retour annuels
> entre 5 et 7 %.

A noter également qu'en activant la fonction Trim sur des SSD OCZ, pas
mal d'utilisateurs subissent des ralentissements temporaires.

c'est un peu normal quand on active le trim sur un disque qui a été pas
mal utilisé auparavant sans trim : il y a plein de pages vidées par le
système de fichiers, dont le SSD n'était pas au courant.
le fait d'activer le trim va "libérer" du jour au lendemain toutes ces
pages pour le garbage collector, qui, du coup, se retrouve avec plein de
travail à faire...

normalement, ça se stabilise.

Après, pour les 2 SSD vertex que j'ai essayé, dès qu'ils étaient sur une
machine qui les poussait un peu dans leur retranchements, j'avais des
milliers d'erreurs CRC et la roue qui tournait.

je crois que les OCZ et leur timings poussés à bout et leur optimisation
"pour les benchs" ne sont vraiment pas bien adaptés aux nappes SATA pas
tout à fait dans les normes des macbook pro, par exemple.

J'ai fait le test sous 10.6.8 et 10.7.1 : avec Trim activé pour un Vertex
III des gels temporaires de 15 à 20 secondes plusieurs fois par heure.
Une fois le Trim désactivé, tout est rentré dans l'ordre.

Normalement les fonctions trim sont envoyées par lot, et c'est vrai
qu'elles provoquent des interruptions.

Mais si une interruption de quelques dizaines de milisecondes est
normale (acceptable pour un ordi de bureau, pas pour un serveur), 15 à
20 secondes c'est absolument anormal...

OCZ sort tellement de modèles et ils font tellement peu de R&D par
rapport à samsung et intel que c'est impossible qu'ils testent tous
leurs modèles dans tous les Mac.
Ils ont mis des mois à ne serait-ce qu'identifier les incompatibilités
complètes entre leurs disques et Bootcamp sur certaines machines, et les
erreurs CRC.

Tu pourrais peut-être télécharger smart utility et regarder si il y a
des erreurs CRC...

Je pense d'ailleurs remplacer cet OCZ par un Intel avant d'être
réellement planté. :)

Ben franchement, j'hésite plus jamais moi : entre les quelques petits
chouillats de performance en plus des OCZ, et la tranquilité d'esprit
d'un intel (qui reste un monstre de performances par rapport à un HD
classique), j'hésite pas...

j'ai recyclé les 2 OCZ que j'ai eu dans des machines en SATA-I, comme
ça, je suis tranquille...

Par contre, une fois le SSD adopté pour le disque système, c'est
difficile de revenir à un système sur disque dur traditionnel, on
s'habitue vite à la vitesse de boot et de chargement des applications...

ah ça... c'est dur de convaincre les utilisateurs que pour le même prix,
un baril de SSD vaut mieux que plusieurs barils de processeurs, mais une
fois que c'est fait, comme tu dis plus personne ne revient en arrière.

La Bete des Vosges (Francis Chartier)

01/11/2011 à 19:15

Le Tue, 01 Nov 2011 14:12:08 +0100, Gilles Aurejac a écrit :

Après, pour les 2 SSD vertex que j'ai essayé, dès qu'ils étaient sur une
machine qui les poussait un peu dans leur retranchements, j'avais des
milliers d'erreurs CRC et la roue qui tournait.

Pas d'erreurs CRC mais des freeze de plusieurs secondes avec la "spinning
beach ball" avant la reprise de l'activité normale, et ce de manière
récurrente.

OCZ sort tellement de modèles et ils font tellement peu de R&D par
rapport à samsung et intel que c'est impossible qu'ils testent tous
leurs modèles dans tous les Mac.
Ils ont mis des mois à ne serait-ce qu'identifier les incompatibilités
complètes entre leurs disques et Bootcamp sur certaines machines, et les
erreurs CRC.

Sans compter les nombreuses updates de firmware qui ne resolvent pas les
problèmes, et sont galères à appliquer sur Mac.

Tu pourrais peut-être télécharger smart utility et regarder si il y a
des erreurs CRC...

Smartctl (des smartmontools sous port) non plus qu'Onyx ne révèlent
d'erreurs, le disque paraît OK.
Mais je n'ai plus trop confiance, et ce n'est pas la lecture des forums
OCZ qui va me rassurer. :)

j'ai recyclé les 2 OCZ que j'ai eu dans des machines en SATA-I, comme
ça, je suis tranquille...

Je vais finir par le brancher sur un adaptateur IDE/Sata et le coller
dans un enregistreur TNT où son silence va faire des merveilles.

ah ça... c'est dur de convaincre les utilisateurs que pour le même prix,
un baril de SSD vaut mieux que plusieurs barils de processeurs, mais une
fois que c'est fait, comme tu dis plus personne ne revient en arrière.

Voilà : de la RAM et un SSD, ça donne une nouvelle jeunesse à bien des
machines.

--
La Bête des Vosges

patpro ~ patrick proniewski

01/11/2011 à 20:08

In article <1ka22b7.1hjzcec19czma4N%,
(Gilles Aurejac) wrote:

Normalement les fonctions trim sont envoyées par lot, et c'est vrai
qu'elles provoquent des interruptions.

a priori les commandes trim ne peuvent pas être mises en queue,
contrairement aux autres commandes, donc pour qu'une commande trim
s'exécute, il faut que la queue de commande SATA soit vide. Ça peut
expliquer les interruptions.

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133

patpro ~ patrick proniewski

01/11/2011 à 20:13

In article <1ka223s.13z102q1qka8wgN%,
(Gilles Aurejac) wrote:

> ha ben celui là "je l'aura pas", c'est sûr. Il coute juste la moitié de
> mon appartement.

ça fait un peu cher pour lancer MacSoup :-)

MacSoup c'est pour les fillettes, j'utilise MT-NewsWatcher :')

> Dans un Mac Pro, les autres machines c'est pour les fillettes.

Désolé c'était un peu de la provoc, sachant les rumeurs qui circulent
ces jours-ci sur la disparition des mac pro, qui semble terriblement
dans la logique actuelle, et qui ferait pas mon bonheur...

bah, les gens ne jurent que par les iBidules, ils ne s'en apercevront
même pas.

> (ou alors
> dans mon serveur supermicro, sous FreeBSD avec ZFS, mais j'arrive déjà
> pas à utiliser toute la RAM alors...)

bah, tu peux la recycler dans un mac pro...

c'est pas la même, mais bon, je suis tranquille pour un moment. Vaut
mieux avoir trop de RAM que pas assez.

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133

gquerat

03/11/2011 à 17:09

Gilles Querat wrote:

Hello,

je me prépare à bientôt installer une nouvelle machine avec un SSD 256
Go. (iMac i7 avec 1 SSD et 1 DD 1To)

Merci à tous pour vos avis et commentaires techniques. j'en retiens que
je n'ai pas à stresser outre mesures....

--
Gilles Querat
Luminy Les Calanques

disque SSD et fichiers temporaires

10 réponses

Veuillez sélectionner un problème