Francois Lafont a écrit :
>
> Mais alors, si jamais on monte un disque SSD sans l'option discard _et_ sans
> prendre le soin de faire un fstrim régulièrement, alors que se passe-t-il ?
> Le disque va se remplir inexorablement au fil du temps
Oui, en quelque sorte.
> et à un moment donné je ne pourrai tout simplement plus écrire dessus
Non, quand même pas. Mais les écritures seront beaucoup plus coûteuses.
> Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
> seul comme un grand, quand ça l'arrange.
C'est impossible puisque le TRIM sert justement à l'informer des blocs
qui ne sont plus occupés. Certains SSD ont essayé de faire ça
d'eux-mêmes mais ne savaient lire que NTFS. Inutile de dire qu'avec les
autres systèmes de fichiers, ça a été la catastrophe.
> En fait, je pensais même que le discard ou le fstrim auraient même tendance à
> diminuer la durée de vie du SSD vu que ça l'oblige à effacer des cellules à un
> moment où, peut-être, ce n'est pas nécessaire.
Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.
Un peu d'explication.
Bien que la finalité soit la même, un SSD fonctionne très différemment
d'un disque dur.
Un disque dur est divisé en secteurs indépendants les uns des autres (à
l'exception des disques au format avancé 512e où plusieurs secteurs
logiques sont regroupés dans un secteur physique, mais on va faire
l'impasse). Chaque secteur a un contenu (que ce soit des zéros ou autre
chose n'a pas d'importance) et la modification de ce contenu se fait
simplement en écrivant par dessus, comme une bande magnétique. Il y a
une correspondance entre l'adresse logique d'un secteur et sa position
physique sur le disque (à l'exception des secteurs défectueux qui ont
été réalloués).
Un SSD est très différent. Les secteurs ne sont pas indépendants : ils
sont regroupés en pages (typiquement 4 ou 8 Kio), et les pages sont
regroupées en blocs d'effacement (typiquement 1 Mio). L'écriture ne peut
se faire que sur une page entière, mais il y a pire : on ne peut écrire
que dans une page préalablement effacée. On ne peut pas réécrire
directement par dessus une page qui a déjà été écrite, il faut d'abord
effacer tout le bloc qui la contient. Or l'effacement d'un bloc est une
opération coûteuse, en temps et en usure des cellules.
C'est un peu comme écrire au crayon sur une feuille de papier : pour
réécrire au même endroit, il faut d'abord effacer à la gomme, ce qui use
le papier. A la longue, à force de gommer un emplacement, le papier
devient trop usé et inutilisable.
Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
avoir besoin d'effacer. Quand les données d'une page doivent être
modifiées, on écrit les nouvelles données dans une autre page vide et on
marque l'anciene page comme obsolète. C'est rapide. Au passage on devine
qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
position physique. Si on ne fait rien, à force d'écrire et de modifier
les données, toutes les pages vont finir par être écrites, qu'elles
contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
il va falloir effacer des blocs de pages contenant des données
obsolètes. Si toutes les pages d'un bloc contiennent des données
obsolètes, il suffit d'effacer le bloc. Mais si certaines pages du bloc
contiennent des données actuelles, il faut les copier dans une mémoire
tampon, effacer le bloc et réécrire les données.
On ne peut pas faire ça à chaque nouvelle écriture, ce serait trop
coûteux en temps et en usure. Pour éviter cette situation, le SSA
procède régulièrement à un "ramasse-miettes" (garbage collection). Cela
consiste à transférer les données des pages actuelles dans de nouveaux
blocs et d'effacer les anciens blocs. Le but est de toujours disposer de
suffisamment de pages vides d'avance pour que l'écriture reste rapide.
Il ne faut pas le faire trop souvent non plus car, comme tout
effacement, cela augmente l'usure.
C'est notamment ici que le TRIM intervient : en marquant des secteurs
comme obsolètes lors de l'effacement d'un fichier, il facilite le
ramasse-miettes. Pour que cela soit efficace il vaut mieux que le
système d'exploitation utilise comme unité de stockage des blocs de
secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
contraintes nouvelles d'alignement des partitions), ainsi tous les
secteurs d'une page seront marqués en même temps et la page pourra être
écartée.
Le TRIM en lui-même ne fait que marquer les données obsolètes, il
n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
fonction du nombre de blocs libres et du taux d'écriture.
Francois Lafont a écrit :
>
> Mais alors, si jamais on monte un disque SSD sans l'option discard _et_ sans
> prendre le soin de faire un fstrim régulièrement, alors que se passe-t-il ?
> Le disque va se remplir inexorablement au fil du temps
Oui, en quelque sorte.
> et à un moment donné je ne pourrai tout simplement plus écrire dessus
Non, quand même pas. Mais les écritures seront beaucoup plus coûteuses.
> Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
> seul comme un grand, quand ça l'arrange.
C'est impossible puisque le TRIM sert justement à l'informer des blocs
qui ne sont plus occupés. Certains SSD ont essayé de faire ça
d'eux-mêmes mais ne savaient lire que NTFS. Inutile de dire qu'avec les
autres systèmes de fichiers, ça a été la catastrophe.
> En fait, je pensais même que le discard ou le fstrim auraient même tendance à
> diminuer la durée de vie du SSD vu que ça l'oblige à effacer des cellules à un
> moment où, peut-être, ce n'est pas nécessaire.
Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.
Un peu d'explication.
Bien que la finalité soit la même, un SSD fonctionne très différemment
d'un disque dur.
Un disque dur est divisé en secteurs indépendants les uns des autres (à
l'exception des disques au format avancé 512e où plusieurs secteurs
logiques sont regroupés dans un secteur physique, mais on va faire
l'impasse). Chaque secteur a un contenu (que ce soit des zéros ou autre
chose n'a pas d'importance) et la modification de ce contenu se fait
simplement en écrivant par dessus, comme une bande magnétique. Il y a
une correspondance entre l'adresse logique d'un secteur et sa position
physique sur le disque (à l'exception des secteurs défectueux qui ont
été réalloués).
Un SSD est très différent. Les secteurs ne sont pas indépendants : ils
sont regroupés en pages (typiquement 4 ou 8 Kio), et les pages sont
regroupées en blocs d'effacement (typiquement 1 Mio). L'écriture ne peut
se faire que sur une page entière, mais il y a pire : on ne peut écrire
que dans une page préalablement effacée. On ne peut pas réécrire
directement par dessus une page qui a déjà été écrite, il faut d'abord
effacer tout le bloc qui la contient. Or l'effacement d'un bloc est une
opération coûteuse, en temps et en usure des cellules.
C'est un peu comme écrire au crayon sur une feuille de papier : pour
réécrire au même endroit, il faut d'abord effacer à la gomme, ce qui use
le papier. A la longue, à force de gommer un emplacement, le papier
devient trop usé et inutilisable.
Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
avoir besoin d'effacer. Quand les données d'une page doivent être
modifiées, on écrit les nouvelles données dans une autre page vide et on
marque l'anciene page comme obsolète. C'est rapide. Au passage on devine
qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
position physique. Si on ne fait rien, à force d'écrire et de modifier
les données, toutes les pages vont finir par être écrites, qu'elles
contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
il va falloir effacer des blocs de pages contenant des données
obsolètes. Si toutes les pages d'un bloc contiennent des données
obsolètes, il suffit d'effacer le bloc. Mais si certaines pages du bloc
contiennent des données actuelles, il faut les copier dans une mémoire
tampon, effacer le bloc et réécrire les données.
On ne peut pas faire ça à chaque nouvelle écriture, ce serait trop
coûteux en temps et en usure. Pour éviter cette situation, le SSA
procède régulièrement à un "ramasse-miettes" (garbage collection). Cela
consiste à transférer les données des pages actuelles dans de nouveaux
blocs et d'effacer les anciens blocs. Le but est de toujours disposer de
suffisamment de pages vides d'avance pour que l'écriture reste rapide.
Il ne faut pas le faire trop souvent non plus car, comme tout
effacement, cela augmente l'usure.
C'est notamment ici que le TRIM intervient : en marquant des secteurs
comme obsolètes lors de l'effacement d'un fichier, il facilite le
ramasse-miettes. Pour que cela soit efficace il vaut mieux que le
système d'exploitation utilise comme unité de stockage des blocs de
secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
contraintes nouvelles d'alignement des partitions), ainsi tous les
secteurs d'une page seront marqués en même temps et la page pourra être
écartée.
Le TRIM en lui-même ne fait que marquer les données obsolètes, il
n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
fonction du nombre de blocs libres et du taux d'écriture.
Francois Lafont a écrit :
>
> Mais alors, si jamais on monte un disque SSD sans l'option discard _et_ sans
> prendre le soin de faire un fstrim régulièrement, alors que se passe-t-il ?
> Le disque va se remplir inexorablement au fil du temps
Oui, en quelque sorte.
> et à un moment donné je ne pourrai tout simplement plus écrire dessus
Non, quand même pas. Mais les écritures seront beaucoup plus coûteuses.
> Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
> seul comme un grand, quand ça l'arrange.
C'est impossible puisque le TRIM sert justement à l'informer des blocs
qui ne sont plus occupés. Certains SSD ont essayé de faire ça
d'eux-mêmes mais ne savaient lire que NTFS. Inutile de dire qu'avec les
autres systèmes de fichiers, ça a été la catastrophe.
> En fait, je pensais même que le discard ou le fstrim auraient même tendance à
> diminuer la durée de vie du SSD vu que ça l'oblige à effacer des cellules à un
> moment où, peut-être, ce n'est pas nécessaire.
Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.
Un peu d'explication.
Bien que la finalité soit la même, un SSD fonctionne très différemment
d'un disque dur.
Un disque dur est divisé en secteurs indépendants les uns des autres (à
l'exception des disques au format avancé 512e où plusieurs secteurs
logiques sont regroupés dans un secteur physique, mais on va faire
l'impasse). Chaque secteur a un contenu (que ce soit des zéros ou autre
chose n'a pas d'importance) et la modification de ce contenu se fait
simplement en écrivant par dessus, comme une bande magnétique. Il y a
une correspondance entre l'adresse logique d'un secteur et sa position
physique sur le disque (à l'exception des secteurs défectueux qui ont
été réalloués).
Un SSD est très différent. Les secteurs ne sont pas indépendants : ils
sont regroupés en pages (typiquement 4 ou 8 Kio), et les pages sont
regroupées en blocs d'effacement (typiquement 1 Mio). L'écriture ne peut
se faire que sur une page entière, mais il y a pire : on ne peut écrire
que dans une page préalablement effacée. On ne peut pas réécrire
directement par dessus une page qui a déjà été écrite, il faut d'abord
effacer tout le bloc qui la contient. Or l'effacement d'un bloc est une
opération coûteuse, en temps et en usure des cellules.
C'est un peu comme écrire au crayon sur une feuille de papier : pour
réécrire au même endroit, il faut d'abord effacer à la gomme, ce qui use
le papier. A la longue, à force de gommer un emplacement, le papier
devient trop usé et inutilisable.
Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
avoir besoin d'effacer. Quand les données d'une page doivent être
modifiées, on écrit les nouvelles données dans une autre page vide et on
marque l'anciene page comme obsolète. C'est rapide. Au passage on devine
qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
position physique. Si on ne fait rien, à force d'écrire et de modifier
les données, toutes les pages vont finir par être écrites, qu'elles
contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
il va falloir effacer des blocs de pages contenant des données
obsolètes. Si toutes les pages d'un bloc contiennent des données
obsolètes, il suffit d'effacer le bloc. Mais si certaines pages du bloc
contiennent des données actuelles, il faut les copier dans une mémoire
tampon, effacer le bloc et réécrire les données.
On ne peut pas faire ça à chaque nouvelle écriture, ce serait trop
coûteux en temps et en usure. Pour éviter cette situation, le SSA
procède régulièrement à un "ramasse-miettes" (garbage collection). Cela
consiste à transférer les données des pages actuelles dans de nouveaux
blocs et d'effacer les anciens blocs. Le but est de toujours disposer de
suffisamment de pages vides d'avance pour que l'écriture reste rapide.
Il ne faut pas le faire trop souvent non plus car, comme tout
effacement, cela augmente l'usure.
C'est notamment ici que le TRIM intervient : en marquant des secteurs
comme obsolètes lors de l'effacement d'un fichier, il facilite le
ramasse-miettes. Pour que cela soit efficace il vaut mieux que le
système d'exploitation utilise comme unité de stockage des blocs de
secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
contraintes nouvelles d'alignement des partitions), ainsi tous les
secteurs d'une page seront marqués en même temps et la page pourra être
écartée.
Le TRIM en lui-même ne fait que marquer les données obsolètes, il
n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
fonction du nombre de blocs libres et du taux d'écriture.
Ok, donc si je comprends bien le SSD n'est pas capable de distinguer les pages
qui contiennent des données devenues inutiles pour le file system de celles
qui restent encore d'actualité (ie utiles pour le fs).
Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.
Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
avoir besoin d'effacer. Quand les données d'une page doivent être
modifiées, on écrit les nouvelles données dans une autre page vide et on
marque l'ancienne page comme obsolète. C'est rapide. Au passage on devine
qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
position physique. Si on ne fait rien, à force d'écrire et de modifier
les données, toutes les pages vont finir par être écrites, qu'elles
contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
il va falloir effacer des blocs de pages contenant des données
obsolètes.
Mais là, je ne pige pas. Si le SSD n'est pas capable de savoir ce qui
est actuel de ce qui est obsolètes sans TRIM, je ne vois pas comment
il fait pour dégager de la place pour les prochaines écritures ? Si jamais
je n'utilise pas l'option de montage discard et si en plus je ne lance _jamais_
la commande fstrim, comment fait le SSD pour déterminer tout seul les data
qui sont obsolètes de celles qui ne le sont pas ?
Ok, mais je ne vois pas comment le garbage collector du SSD va faire
du coup pour savoir ce qui obsolète de ce qui ne l'est pas puisque j'ai
cru comprendre qu'il ne pouvait pas le savoir sans le lancement de fstrim ?
Pour que cela soit efficace il vaut mieux que le
système d'exploitation utilise comme unité de stockage des blocs de
secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
contraintes nouvelles d'alignement des partitions),
Si je fais commencer mes partitions à 1MiB, suis-je à l'abri de problèmes d'alignement ?
Le TRIM en lui-même ne fait que marquer les données obsolètes, il
n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
fonction du nombre de blocs libres et du taux d'écriture.
Ok, mais alors comme ça a été dit dans un message précédent, il est recommandé
de faire un fstrim une fois par semaine, c'est ça ?
Je n'arrive plus à retrouver le lien probant mais il me semble bien avoir lu
quelque part que faire un fstrim de temps en temps n'était pas nécessaire sur
certains disques SSD, est-ce vrai ? Par exemple (certes ce n'est pas très probant
comme lien), ici http://www.mail-archive.com/ceph-users%40lists.ceph.com/msg12756.html
un admin écrit :
« Of course if you're using Intel DC 3700S SSDs you probably won't get any
speed benefit from this at least, they're never slowing down. ^^ »
On est d'accord que fstrim est valable uniquement pour des partitions avec
file system, n'est-ce pas ? Par exemple si une application utilise un partition
brute sans file system (je pense à Ceph par exemple qui utilise des partitions
brutes où il écrit de manière séquentielle dessus), alors le fstrim n'y est
pas nécessaire ?
Ok, donc si je comprends bien le SSD n'est pas capable de distinguer les pages
qui contiennent des données devenues inutiles pour le file system de celles
qui restent encore d'actualité (ie utiles pour le fs).
Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.
Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
avoir besoin d'effacer. Quand les données d'une page doivent être
modifiées, on écrit les nouvelles données dans une autre page vide et on
marque l'ancienne page comme obsolète. C'est rapide. Au passage on devine
qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
position physique. Si on ne fait rien, à force d'écrire et de modifier
les données, toutes les pages vont finir par être écrites, qu'elles
contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
il va falloir effacer des blocs de pages contenant des données
obsolètes.
Mais là, je ne pige pas. Si le SSD n'est pas capable de savoir ce qui
est actuel de ce qui est obsolètes sans TRIM, je ne vois pas comment
il fait pour dégager de la place pour les prochaines écritures ? Si jamais
je n'utilise pas l'option de montage discard et si en plus je ne lance _jamais_
la commande fstrim, comment fait le SSD pour déterminer tout seul les data
qui sont obsolètes de celles qui ne le sont pas ?
Ok, mais je ne vois pas comment le garbage collector du SSD va faire
du coup pour savoir ce qui obsolète de ce qui ne l'est pas puisque j'ai
cru comprendre qu'il ne pouvait pas le savoir sans le lancement de fstrim ?
Pour que cela soit efficace il vaut mieux que le
système d'exploitation utilise comme unité de stockage des blocs de
secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
contraintes nouvelles d'alignement des partitions),
Si je fais commencer mes partitions à 1MiB, suis-je à l'abri de problèmes d'alignement ?
Le TRIM en lui-même ne fait que marquer les données obsolètes, il
n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
fonction du nombre de blocs libres et du taux d'écriture.
Ok, mais alors comme ça a été dit dans un message précédent, il est recommandé
de faire un fstrim une fois par semaine, c'est ça ?
Je n'arrive plus à retrouver le lien probant mais il me semble bien avoir lu
quelque part que faire un fstrim de temps en temps n'était pas nécessaire sur
certains disques SSD, est-ce vrai ? Par exemple (certes ce n'est pas très probant
comme lien), ici http://www.mail-archive.com/ceph-users%40lists.ceph.com/msg12756.html
un admin écrit :
« Of course if you're using Intel DC 3700S SSDs you probably won't get any
speed benefit from this at least, they're never slowing down. ^^ »
On est d'accord que fstrim est valable uniquement pour des partitions avec
file system, n'est-ce pas ? Par exemple si une application utilise un partition
brute sans file system (je pense à Ceph par exemple qui utilise des partitions
brutes où il écrit de manière séquentielle dessus), alors le fstrim n'y est
pas nécessaire ?
Ok, donc si je comprends bien le SSD n'est pas capable de distinguer les pages
qui contiennent des données devenues inutiles pour le file system de celles
qui restent encore d'actualité (ie utiles pour le fs).
Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.
Au début, toutes les pages sont vides, tout va bien. On écrit donc sans
avoir besoin d'effacer. Quand les données d'une page doivent être
modifiées, on écrit les nouvelles données dans une autre page vide et on
marque l'ancienne page comme obsolète. C'est rapide. Au passage on devine
qu'il n'y a plus de correspondance entre l'adresse d'un secteur et sa
position physique. Si on ne fait rien, à force d'écrire et de modifier
les données, toutes les pages vont finir par être écrites, qu'elles
contiennent des données obsolètes ou actuelles. Pour continuer à écrire,
il va falloir effacer des blocs de pages contenant des données
obsolètes.
Mais là, je ne pige pas. Si le SSD n'est pas capable de savoir ce qui
est actuel de ce qui est obsolètes sans TRIM, je ne vois pas comment
il fait pour dégager de la place pour les prochaines écritures ? Si jamais
je n'utilise pas l'option de montage discard et si en plus je ne lance _jamais_
la commande fstrim, comment fait le SSD pour déterminer tout seul les data
qui sont obsolètes de celles qui ne le sont pas ?
Ok, mais je ne vois pas comment le garbage collector du SSD va faire
du coup pour savoir ce qui obsolète de ce qui ne l'est pas puisque j'ai
cru comprendre qu'il ne pouvait pas le savoir sans le lancement de fstrim ?
Pour que cela soit efficace il vaut mieux que le
système d'exploitation utilise comme unité de stockage des blocs de
secteurs coïncident avec une ou plusieurs pages du SSD (d'où les
contraintes nouvelles d'alignement des partitions),
Si je fais commencer mes partitions à 1MiB, suis-je à l'abri de problèmes d'alignement ?
Le TRIM en lui-même ne fait que marquer les données obsolètes, il
n'efface rien. Un firmware de SSD bien conçu ne devrait pas déclencher
le ramasse-miette en fonction de la fréquence du TRIM mais seulement en
fonction du nombre de blocs libres et du taux d'écriture.
Ok, mais alors comme ça a été dit dans un message précédent, il est recommandé
de faire un fstrim une fois par semaine, c'est ça ?
Je n'arrive plus à retrouver le lien probant mais il me semble bien avoir lu
quelque part que faire un fstrim de temps en temps n'était pas nécessaire sur
certains disques SSD, est-ce vrai ? Par exemple (certes ce n'est pas très probant
comme lien), ici http://www.mail-archive.com/ceph-users%40lists.ceph.com/msg12756.html
un admin écrit :
« Of course if you're using Intel DC 3700S SSDs you probably won't get any
speed benefit from this at least, they're never slowing down. ^^ »
On est d'accord que fstrim est valable uniquement pour des partitions avec
file system, n'est-ce pas ? Par exemple si une application utilise un partition
brute sans file system (je pense à Ceph par exemple qui utilise des partitions
brutes où il écrit de manière séquentielle dessus), alors le fstrim n'y est
pas nécessaire ?
On peut lire ici ou là qu'il est nécessaire (en terme d'optimisation) de
laisser de l'espace libre sur le ssd (donc un espace non partitionné).
Est-ce réellement utile ?
On peut lire ici ou là qu'il est nécessaire (en terme d'optimisation) de
laisser de l'espace libre sur le ssd (donc un espace non partitionné).
Est-ce réellement utile ?
On peut lire ici ou là qu'il est nécessaire (en terme d'optimisation) de
laisser de l'espace libre sur le ssd (donc un espace non partitionné).
Est-ce réellement utile ?
> - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> mémoire ou plus pour éviter des écritures inutiles.
/tmp/ et /var/tmp/
> - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> mémoire ou plus pour éviter des écritures inutiles.
/tmp/ et /var/tmp/
> - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> mémoire ou plus pour éviter des écritures inutiles.
/tmp/ et /var/tmp/
On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > mémoire ou plus pour éviter des écritures inutiles.
>
> /tmp/ et /var/tmp/
Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
la différence avec /tmp, dont la préservation est facultative).
On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > mémoire ou plus pour éviter des écritures inutiles.
>
> /tmp/ et /var/tmp/
Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
la différence avec /tmp, dont la préservation est facultative).
On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > mémoire ou plus pour éviter des écritures inutiles.
>
> /tmp/ et /var/tmp/
Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
la différence avec /tmp, dont la préservation est facultative).
On 17/01/2016 20:41, Pascal Hambourg wrote:
> C'est impossible puisque le TRIM sert justement à l'informer des blocs
> qui ne sont plus occupés. Certains SSD ont essayé de faire ça
> d'eux-mêmes mais ne savaient lire que NTFS. Inutile de dire qu'avec les
> autres systèmes de fichiers, ça a été la catastrophe.
Ok, donc si je comprends bien le SSD n'est pas capable de distinguer
les pages qui contiennent des données devenues inutiles pour le file
system de celles qui restent encore d'actualité (ie utiles pour le
fs).
> Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.
Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.
Mais là, je ne pige pas. Si le SSD n'est pas capable de savoir ce
qui est actuel de ce qui est obsolètes sans TRIM, je ne vois pas
comment il fait pour dégager de la place pour les prochaines
écritures ? Si jamais je n'utilise pas l'option de montage discard
et si en plus je ne lance _jamais_ la commande fstrim, comment fait
le SSD pour déterminer tout seul les data qui sont obsolètes de
celles qui ne le sont pas ?
On 17/01/2016 20:41, Pascal Hambourg wrote:
> C'est impossible puisque le TRIM sert justement à l'informer des blocs
> qui ne sont plus occupés. Certains SSD ont essayé de faire ça
> d'eux-mêmes mais ne savaient lire que NTFS. Inutile de dire qu'avec les
> autres systèmes de fichiers, ça a été la catastrophe.
Ok, donc si je comprends bien le SSD n'est pas capable de distinguer
les pages qui contiennent des données devenues inutiles pour le file
system de celles qui restent encore d'actualité (ie utiles pour le
fs).
> Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.
Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.
Mais là, je ne pige pas. Si le SSD n'est pas capable de savoir ce
qui est actuel de ce qui est obsolètes sans TRIM, je ne vois pas
comment il fait pour dégager de la place pour les prochaines
écritures ? Si jamais je n'utilise pas l'option de montage discard
et si en plus je ne lance _jamais_ la commande fstrim, comment fait
le SSD pour déterminer tout seul les data qui sont obsolètes de
celles qui ne le sont pas ?
On 17/01/2016 20:41, Pascal Hambourg wrote:
> C'est impossible puisque le TRIM sert justement à l'informer des blocs
> qui ne sont plus occupés. Certains SSD ont essayé de faire ça
> d'eux-mêmes mais ne savaient lire que NTFS. Inutile de dire qu'avec les
> autres systèmes de fichiers, ça a été la catastrophe.
Ok, donc si je comprends bien le SSD n'est pas capable de distinguer
les pages qui contiennent des données devenues inutiles pour le file
system de celles qui restent encore d'actualité (ie utiles pour le
fs).
> Rien n'oblige le SSD a effacer immédiatement suite à une commande TRIM.
Ok, TRIM indique seulement au SSD les data qui sont devenues inutiles au fs.
Mais là, je ne pige pas. Si le SSD n'est pas capable de savoir ce
qui est actuel de ce qui est obsolètes sans TRIM, je ne vois pas
comment il fait pour dégager de la place pour les prochaines
écritures ? Si jamais je n'utilise pas l'option de montage discard
et si en plus je ne lance _jamais_ la commande fstrim, comment fait
le SSD pour déterminer tout seul les data qui sont obsolètes de
celles qui ne le sont pas ?
Bonjour,
Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > mémoire ou plus pour éviter des écritures inutiles.
> >
> > /tmp/ et /var/tmp/
>
> Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> la différence avec /tmp, dont la préservation est facultative).
Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
bien sûr se modifier.
Bonjour,
Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > mémoire ou plus pour éviter des écritures inutiles.
> >
> > /tmp/ et /var/tmp/
>
> Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> la différence avec /tmp, dont la préservation est facultative).
Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
bien sûr se modifier.
Bonjour,
Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > mémoire ou plus pour éviter des écritures inutiles.
> >
> > /tmp/ et /var/tmp/
>
> Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> la différence avec /tmp, dont la préservation est facultative).
Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
bien sûr se modifier.
Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.
Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.
Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.
On 2016-01-18 14:16:31 +0100, Sébastien NOBILI wrote:
> Bonjour,
>
> Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> > On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > > mémoire ou plus pour éviter des écritures inutiles.
> > >
> > > /tmp/ et /var/tmp/
> >
> > Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> > la différence avec /tmp, dont la préservation est facultative).
>
> Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
> bien sûr se modifier.
Non, je n'ai rien modifié, et:
zira% df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dm-1 471942448 125324444 322621588 28% /
zira% df /var/tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dm-1 471942448 125324444 322621588 28% /
(machine installée en Jessie, puis mise à jour en unstable).
On 2016-01-18 14:16:31 +0100, Sébastien NOBILI wrote:
> Bonjour,
>
> Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> > On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > > mémoire ou plus pour éviter des écritures inutiles.
> > >
> > > /tmp/ et /var/tmp/
> >
> > Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> > la différence avec /tmp, dont la préservation est facultative).
>
> Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
> bien sûr se modifier.
Non, je n'ai rien modifié, et:
zira% df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dm-1 471942448 125324444 322621588 28% /
zira% df /var/tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dm-1 471942448 125324444 322621588 28% /
(machine installée en Jessie, puis mise à jour en unstable).
On 2016-01-18 14:16:31 +0100, Sébastien NOBILI wrote:
> Bonjour,
>
> Le lundi 18 janvier 2016 à 14:06, Vincent Lefevre a écrit :
> > On 2016-01-17 14:21:39 +0100, Sébastien Dinot wrote:
> > > > - le répertoire /tmp monté en tmpfs pour les machines de 8Go de
> > > > mémoire ou plus pour éviter des écritures inutiles.
> > >
> > > /tmp/ et /var/tmp/
> >
> > Certainement pas /var/tmp, qui doit être préservé après reboot (c'est
> > la différence avec /tmp, dont la préservation est facultative).
>
> Depuis Jessie, /var/tmp/ est devenu un montage tmpfs, mais ça peut
> bien sûr se modifier.
Non, je n'ai rien modifié, et:
zira% df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dm-1 471942448 125324444 322621588 28% /
zira% df /var/tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dm-1 471942448 125324444 322621588 28% /
(machine installée en Jessie, puis mise à jour en unstable).
On 2016-01-18 09:43:35 +0100, Pascal Hambourg wrote:Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.
J'ai des doutes là-dessus. Lorsqu'il y a une modification d'un
fichier:
1) Si le système cherche à réécrire sur les pages utilisées, ça va
provoquer des effacements / copies, ce qui est lent.
2) S'il cherche au contraire à utiliser des zones libres (tant qu'il
y en a), il va prendre de plus en plus de données, tel que c'est
vu par le SSD. Et au bout d'un moment, tout sera occupé, et on
retombe dans le cas 1 (s'il ne fait pas lui-même de TRIM).
On 2016-01-18 09:43:35 +0100, Pascal Hambourg wrote:
Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.
J'ai des doutes là-dessus. Lorsqu'il y a une modification d'un
fichier:
1) Si le système cherche à réécrire sur les pages utilisées, ça va
provoquer des effacements / copies, ce qui est lent.
2) S'il cherche au contraire à utiliser des zones libres (tant qu'il
y en a), il va prendre de plus en plus de données, tel que c'est
vu par le SSD. Et au bout d'un moment, tout sera occupé, et on
retombe dans le cas 1 (s'il ne fait pas lui-même de TRIM).
On 2016-01-18 09:43:35 +0100, Pascal Hambourg wrote:Je n'ai pas regardé cette page, mais certains SSD haut de gamme ont un
taux d'overprovisionning élevé, pouvant aller jusqu'à 100%. Dans ce cas
il reste toujours une grande quantité de blocs libres même sans TRIM, ce
qui permet au ramasse-miettes de fonctionner efficacement. On peut
obtenir un résultat similaire en n'utilisant qu'une fraction de la
capacité utile d'un SSD standard.
J'ai des doutes là-dessus. Lorsqu'il y a une modification d'un
fichier:
1) Si le système cherche à réécrire sur les pages utilisées, ça va
provoquer des effacements / copies, ce qui est lent.
2) S'il cherche au contraire à utiliser des zones libres (tant qu'il
y en a), il va prendre de plus en plus de données, tel que c'est
vu par le SSD. Et au bout d'un moment, tout sera occupé, et on
retombe dans le cas 1 (s'il ne fait pas lui-même de TRIM).