À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Y a pas le support du TRIM en natif, mais certains fabricants de SSD (j'ai en tête Intel et Samsung, mais p'tet d'autres) fournissent dans leur utilitaires un outil pour trimmer, ça ne vaut pas certe le support natif, mais c'est déjà pas mal.
Ca ne trimme pas "en temps réel", si ?
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont libérés dans le système de fichiers (option "discard" lors du montage sous Linux) ? J'ai lu des critiques contre cette approche, car l'exécution de la commande TRIM par le SSD dégraderait ses performances tout le temps de l'opération. Il semble que la tendance soit plutôt de lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
pehache a écrit :
Le 29/11/2014 18:05, Ascadix a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le
TRIM...
Y a pas le support du TRIM en natif, mais certains fabricants de SSD
(j'ai en tête Intel et Samsung, mais p'tet d'autres) fournissent dans
leur utilitaires un outil pour trimmer, ça ne vaut pas certe le support
natif, mais c'est déjà pas mal.
Ca ne trimme pas "en temps réel", si ?
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont
libérés dans le système de fichiers (option "discard" lors du montage
sous Linux) ? J'ai lu des critiques contre cette approche, car
l'exécution de la commande TRIM par le SSD dégraderait ses performances
tout le temps de l'opération. Il semble que la tendance soit plutôt de
lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Y a pas le support du TRIM en natif, mais certains fabricants de SSD (j'ai en tête Intel et Samsung, mais p'tet d'autres) fournissent dans leur utilitaires un outil pour trimmer, ça ne vaut pas certe le support natif, mais c'est déjà pas mal.
Ca ne trimme pas "en temps réel", si ?
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont libérés dans le système de fichiers (option "discard" lors du montage sous Linux) ? J'ai lu des critiques contre cette approche, car l'exécution de la commande TRIM par le SSD dégraderait ses performances tout le temps de l'opération. Il semble que la tendance soit plutôt de lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
Pascal Hambourg
Sergio a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas optimal pour les SSD.
Sergio a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas
optimal pour les SSD.
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas optimal pour les SSD.
Mais ça c'est facile à éviter /corriger
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Ascadix
pehache a exprimé avec précision :
Le 29/11/2014 18:05, Ascadix a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Y a pas le support du TRIM en natif, mais certains fabricants de SSD (j'ai en tête Intel et Samsung, mais p'tet d'autres) fournissent dans leur utilitaires un outil pour trimmer, ça ne vaut pas certe le support natif, mais c'est déjà pas mal.
Ca ne trimme pas "en temps réel", si ?
Sur Samsung non, les autres, je sais pas.
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Interaction entre le FS et le pilote de stockage:
suppression ou réécriture d'un fichier -> écriture de nouveaux blocs de données + maj des structures du FS (référence des nouveauc bloc, et déréférencement des blocs obsolétes) -> TRIM des blocs physiquement libérés
Donc kernel ..ou pas, ça dépend de l'OS, et de son implémentation/interaction entre le pilote du FS et le pilote du périph de stockage.
Pour le TRIM en différé, sur un OS genre Windows sur un FS genre NTFS ou t'as des API de defrag capable de fournir des infos précises sur l'utilisation d'un bloc de cluster, on peut trimer en différé. Sur un Linux, ça dépend, j'imagine que c'est archi-compliqué sur un FS de merde comme EXT3, mais c'est probablement envisageable sur EXST4 avec les API de defrag qui ont été (enfin) intégrés dans l'implémentation du FS. kif kif pour les autre FS utilisable sous nunux.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
pehache a exprimé avec précision :
Le 29/11/2014 18:05, Ascadix a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le
TRIM...
Y a pas le support du TRIM en natif, mais certains fabricants de SSD
(j'ai en tête Intel et Samsung, mais p'tet d'autres) fournissent dans
leur utilitaires un outil pour trimmer, ça ne vaut pas certe le support
natif, mais c'est déjà pas mal.
Ca ne trimme pas "en temps réel", si ?
Sur Samsung non, les autres, je sais pas.
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Interaction entre le FS et le pilote de stockage:
suppression ou réécriture d'un fichier -> écriture de nouveaux blocs de
données + maj des structures du FS (référence des nouveauc bloc, et
déréférencement des blocs obsolétes) -> TRIM des blocs physiquement
libérés
Donc kernel ..ou pas, ça dépend de l'OS, et de son
implémentation/interaction entre le pilote du FS et le pilote du périph
de stockage.
Pour le TRIM en différé, sur un OS genre Windows sur un FS genre NTFS
ou t'as des API de defrag capable de fournir des infos précises sur
l'utilisation d'un bloc de cluster, on peut trimer en différé.
Sur un Linux, ça dépend, j'imagine que c'est archi-compliqué sur un FS
de merde comme EXT3, mais c'est probablement envisageable sur EXST4
avec les API de defrag qui ont été (enfin) intégrés dans
l'implémentation du FS. kif kif pour les autre FS utilisable sous
nunux.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Y a pas le support du TRIM en natif, mais certains fabricants de SSD (j'ai en tête Intel et Samsung, mais p'tet d'autres) fournissent dans leur utilitaires un outil pour trimmer, ça ne vaut pas certe le support natif, mais c'est déjà pas mal.
Ca ne trimme pas "en temps réel", si ?
Sur Samsung non, les autres, je sais pas.
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Interaction entre le FS et le pilote de stockage:
suppression ou réécriture d'un fichier -> écriture de nouveaux blocs de données + maj des structures du FS (référence des nouveauc bloc, et déréférencement des blocs obsolétes) -> TRIM des blocs physiquement libérés
Donc kernel ..ou pas, ça dépend de l'OS, et de son implémentation/interaction entre le pilote du FS et le pilote du périph de stockage.
Pour le TRIM en différé, sur un OS genre Windows sur un FS genre NTFS ou t'as des API de defrag capable de fournir des infos précises sur l'utilisation d'un bloc de cluster, on peut trimer en différé. Sur un Linux, ça dépend, j'imagine que c'est archi-compliqué sur un FS de merde comme EXT3, mais c'est probablement envisageable sur EXST4 avec les API de defrag qui ont été (enfin) intégrés dans l'implémentation du FS. kif kif pour les autre FS utilisable sous nunux.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Pascal Hambourg
Ascadix a écrit :
Pascal Hambourg a formulé la demande :
Sergio a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas optimal pour les SSD.
Mais ça c'est facile à éviter /corriger
Oui, mais est-ce que Windows XP supporte ce type d'alignement ?
Ascadix a écrit :
Pascal Hambourg a formulé la demande :
Sergio a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas
optimal pour les SSD.
Mais ça c'est facile à éviter /corriger
Oui, mais est-ce que Windows XP supporte ce type d'alignement ?
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas optimal pour les SSD.
Mais ça c'est facile à éviter /corriger
Oui, mais est-ce que Windows XP supporte ce type d'alignement ?
Ascadix
Pascal Hambourg a émis l'idée suivante :
Ascadix a écrit :
Pascal Hambourg a formulé la demande :
Sergio a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas optimal pour les SSD.
Mais ça c'est facile à éviter /corriger
Oui, mais est-ce que Windows XP supporte ce type d'alignement ?
Faut croire, puisque c'est le même genre d'alignement recommandé pour des VM et les systemes de DD en RAID, et j'ai des XP et des 2003 qui tournent avec ce genre d'alignement.
Mon PC perso à des DD en RAID0 depuis +10 ans, et XP/Win7 étaient alignées sur multiple de 8/16/32 ko pour tirer les meilleurs perfs du RAID jusqu'a ce que j'y mette du SSD. Les partitions data sont toujours sur le RAID de HDD et alignées aussi.
3 méthodes:
- à la création, créér le partitionnement avec un autre outils que l'install de XP, créér des parttiosn alignées sur multiple de 4ko (souvent, c'est aligné sur 1 Mo pour simlplifier), ensuite installer XP/2203 sans repartitionner.
- au clonage, utiliser un cloneur qui aligne les partition sur le DD de destination
- en place : réaligner la partition avec un outil ad-hoc, par ex celui de Paragon (gratos en v2 à une époque) "Partition Alignment Tool"
Penser aussi si il y a plusieures partition qu'elles doivent outes être alignée sur un multiple de 4ko, pas seulement la partition systéme.
NB: en ce qui concerne 2003, y a même qq trés vieux aqrticles chez MS, d'avant les VM et les SSD, ça concerne l'alignement des partitions de données pour Exchange/SQL sur les systemes RAID, pour les perfs, il faut mieux aligner les partitions sur les strip du RAID. -> créér les partitions en ligne de commande avec diskpart.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Pascal Hambourg a émis l'idée suivante :
Ascadix a écrit :
Pascal Hambourg a formulé la demande :
Sergio a écrit :
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le
TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas
optimal pour les SSD.
Mais ça c'est facile à éviter /corriger
Oui, mais est-ce que Windows XP supporte ce type d'alignement ?
Faut croire, puisque c'est le même genre d'alignement recommandé pour
des VM et les systemes de DD en RAID, et j'ai des XP et des 2003 qui
tournent avec ce genre d'alignement.
Mon PC perso à des DD en RAID0 depuis +10 ans, et XP/Win7 étaient
alignées sur multiple de 8/16/32 ko pour tirer les meilleurs perfs du
RAID jusqu'a ce que j'y mette du SSD.
Les partitions data sont toujours sur le RAID de HDD et alignées aussi.
3 méthodes:
- à la création, créér le partitionnement avec un autre outils que
l'install de XP, créér des parttiosn alignées sur multiple de 4ko
(souvent, c'est aligné sur 1 Mo pour simlplifier), ensuite installer
XP/2203 sans repartitionner.
- au clonage, utiliser un cloneur qui aligne les partition sur le DD de
destination
- en place : réaligner la partition avec un outil ad-hoc, par ex celui
de Paragon (gratos en v2 à une époque) "Partition Alignment Tool"
Penser aussi si il y a plusieures partition qu'elles doivent outes être
alignée sur un multiple de 4ko, pas seulement la partition systéme.
NB: en ce qui concerne 2003, y a même qq trés vieux aqrticles chez MS,
d'avant les VM et les SSD, ça concerne l'alignement des partitions de
données pour Exchange/SQL sur les systemes RAID, pour les perfs, il
faut mieux aligner les partitions sur les strip du RAID. -> créér les
partitions en ligne de commande avec diskpart.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
À un moment du thread on a parlé de Windows XP, qui n'utilise pas le TRIM...
Sans parler de l'alignement par défaut des partitions qui n'est pas optimal pour les SSD.
Mais ça c'est facile à éviter /corriger
Oui, mais est-ce que Windows XP supporte ce type d'alignement ?
Faut croire, puisque c'est le même genre d'alignement recommandé pour des VM et les systemes de DD en RAID, et j'ai des XP et des 2003 qui tournent avec ce genre d'alignement.
Mon PC perso à des DD en RAID0 depuis +10 ans, et XP/Win7 étaient alignées sur multiple de 8/16/32 ko pour tirer les meilleurs perfs du RAID jusqu'a ce que j'y mette du SSD. Les partitions data sont toujours sur le RAID de HDD et alignées aussi.
3 méthodes:
- à la création, créér le partitionnement avec un autre outils que l'install de XP, créér des parttiosn alignées sur multiple de 4ko (souvent, c'est aligné sur 1 Mo pour simlplifier), ensuite installer XP/2203 sans repartitionner.
- au clonage, utiliser un cloneur qui aligne les partition sur le DD de destination
- en place : réaligner la partition avec un outil ad-hoc, par ex celui de Paragon (gratos en v2 à une époque) "Partition Alignment Tool"
Penser aussi si il y a plusieures partition qu'elles doivent outes être alignée sur un multiple de 4ko, pas seulement la partition systéme.
NB: en ce qui concerne 2003, y a même qq trés vieux aqrticles chez MS, d'avant les VM et les SSD, ça concerne l'alignement des partitions de données pour Exchange/SQL sur les systemes RAID, pour les perfs, il faut mieux aligner les partitions sur les strip du RAID. -> créér les partitions en ligne de commande avec diskpart.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
pehache
Le 30/11/2014 10:17, Pascal Hambourg a écrit :
Ca ne trimme pas "en temps réel", si ?
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont libérés dans le système de fichiers (option "discard" lors du montage sous Linux) ? J'ai lu des critiques contre cette approche, car l'exécution de la commande TRIM par le SSD dégraderait ses performances tout le temps de l'opération. Il semble que la tendance soit plutôt de lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
Oui mais ça c'est au contrôleur du disque de décider du moment opportun, pas à l'OS.
Le 30/11/2014 10:17, Pascal Hambourg a écrit :
Ca ne trimme pas "en temps réel", si ?
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont
libérés dans le système de fichiers (option "discard" lors du montage
sous Linux) ? J'ai lu des critiques contre cette approche, car
l'exécution de la commande TRIM par le SSD dégraderait ses performances
tout le temps de l'opération. Il semble que la tendance soit plutôt de
lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
Oui mais ça c'est au contrôleur du disque de décider du moment opportun,
pas à l'OS.
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont libérés dans le système de fichiers (option "discard" lors du montage sous Linux) ? J'ai lu des critiques contre cette approche, car l'exécution de la commande TRIM par le SSD dégraderait ses performances tout le temps de l'opération. Il semble que la tendance soit plutôt de lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
Oui mais ça c'est au contrôleur du disque de décider du moment opportun, pas à l'OS.
Pascal Hambourg
pehache a écrit :
Le 30/11/2014 10:17, Pascal Hambourg a écrit :
Ca ne trimme pas "en temps réel", si ? Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont libérés dans le système de fichiers (option "discard" lors du montage sous Linux) ? J'ai lu des critiques contre cette approche, car l'exécution de la commande TRIM par le SSD dégraderait ses performances tout le temps de l'opération. Il semble que la tendance soit plutôt de lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
Oui mais ça c'est au contrôleur du disque de décider du moment opportun, pas à l'OS.
On pourrait discuter la validité de cette affirmation, le contrôleur du disque n'étant pas forcément le mieux placé pour prendre ce genre de décision.
Mais la question n'est pas là, ce n'est pas si simple. La commande TRIM originelle de l'interface SATA est de type "non-queued", ce qui oblige le système hôte à arrêter toutes les commandes normales d'entrées-sorties pendant son exécution, qui peut prendre beaucoup de temps selon le firmware du disque. Il faut attendre la norme SATA 3.1 pour qu'une nouvelle commande TRIM de type "queued" soit introduite.
pehache a écrit :
Le 30/11/2014 10:17, Pascal Hambourg a écrit :
Ca ne trimme pas "en temps réel", si ?
Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont
libérés dans le système de fichiers (option "discard" lors du montage
sous Linux) ? J'ai lu des critiques contre cette approche, car
l'exécution de la commande TRIM par le SSD dégraderait ses performances
tout le temps de l'opération. Il semble que la tendance soit plutôt de
lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
Oui mais ça c'est au contrôleur du disque de décider du moment opportun,
pas à l'OS.
On pourrait discuter la validité de cette affirmation, le contrôleur du
disque n'étant pas forcément le mieux placé pour prendre ce genre de
décision.
Mais la question n'est pas là, ce n'est pas si simple.
La commande TRIM originelle de l'interface SATA est de type
"non-queued", ce qui oblige le système hôte à arrêter toutes les
commandes normales d'entrées-sorties pendant son exécution, qui peut
prendre beaucoup de temps selon le firmware du disque. Il faut attendre
la norme SATA 3.1 pour qu'une nouvelle commande TRIM de type "queued"
soit introduite.
Ca ne trimme pas "en temps réel", si ? Le TRIM c'est normalement au niveau du kernel que ça se joue, il me semble.
Tu veux dire au fil de l'eau, au fur et à mesure que les blocs sont libérés dans le système de fichiers (option "discard" lors du montage sous Linux) ? J'ai lu des critiques contre cette approche, car l'exécution de la commande TRIM par le SSD dégraderait ses performances tout le temps de l'opération. Il semble que la tendance soit plutôt de lancer le TRIM à intervalles réguliers lorsque le disque est peu sollicité.
Oui mais ça c'est au contrôleur du disque de décider du moment opportun, pas à l'OS.
On pourrait discuter la validité de cette affirmation, le contrôleur du disque n'étant pas forcément le mieux placé pour prendre ce genre de décision.
Mais la question n'est pas là, ce n'est pas si simple. La commande TRIM originelle de l'interface SATA est de type "non-queued", ce qui oblige le système hôte à arrêter toutes les commandes normales d'entrées-sorties pendant son exécution, qui peut prendre beaucoup de temps selon le firmware du disque. Il faut attendre la norme SATA 3.1 pour qu'une nouvelle commande TRIM de type "queued" soit introduite.
