pour mon prochain ordinateur, j'envisageais de mette un ssd interne à
l'ordi pour aller plus vite, pas gros pour pas être trop cher, et de
solliciter plus que maintenant mes dd externes pour les données un peu
grosses
et d'avoir sur mon ssd : système + swap + données courantes pas trop
grosses,
enfin de l'utiliser comme un dd interne presque normal, juste un peu
petit
qu'en pensez vous ?
2 vendeurs m'ont dit que les ssd étaient fragiles il y a un certain
temps, mais que maintenant on est tranquille, "on peut y aller"
et 1 non-vendeur m'a dit que si, c'est encore d'actualité, parce que
10000 écritures ça file à toute vitesse,
du coup ce qu'on fait quand on veut aller vite c'est mettre le système
et les logiciels sur le ssd, mais surtout jamais le swap, et même pas
les données personnelles
alors en regardant ce qui existe j'envisage 2 extrêmes :
- un ssd bien garanti
https://www.ldlc.com/fiche/PB00170018.html
- un ssd pas trop bon marché pour tout sauf le swap
https://www.ldlc.com/fiche/PB00208741.html
+ un ssd bon marché pour le swap, que je prévois de changer des que
nécessaire
https://www.ldlc.com/fiche/PB00200461.html
jdd , dans le message <5a82f264$0$7583$, a écrit :
j'écris trop en anglais (hibernate)
Tu n'es surtout pas assez soigneux quand tu t'exprimes.
pourtant je viens de vérifier et c'est bien hibernation... jdd -- http://dodin.org
pehache
Le 13/02/2018 à 15:23, jdd a écrit :
Le 13/02/2018 à 13:32, Ascadix a écrit :
Le temps que tu le crame, t'aura changé de PC et tu mettra un SSD/NVME 2* plus gros dedans.
si ton appareil le supporte et que tu peux te le payer, un disque nvme mc2 pcie 250Go est parfait (si tu peux le faire et que tu ne le fais pas tu vas vite le regretter)
A moins d'avoir un usage très exigeant sur la lecture/écriture de très gros fichiers (genre -encore une fois- montage video), la différence de perf perçue au quotidien entre un SSD SATA et un SSD PCIe est insensible. C'est en tous cas ce que je constate entre deux machines comparables à part le type de SSD.
Le 13/02/2018 à 15:23, jdd a écrit :
Le 13/02/2018 à 13:32, Ascadix a écrit :
Le temps que tu le crame, t'aura changé de PC et tu mettra un SSD/NVME
2* plus gros dedans.
si ton appareil le supporte et que tu peux te le payer, un disque nvme
mc2 pcie 250Go est parfait (si tu peux le faire et que tu ne le fais pas
tu vas vite le regretter)
A moins d'avoir un usage très exigeant sur la lecture/écriture de très
gros fichiers (genre -encore une fois- montage video), la différence de
perf perçue au quotidien entre un SSD SATA et un SSD PCIe est insensible.
C'est en tous cas ce que je constate entre deux machines comparables à
part le type de SSD.
Le temps que tu le crame, t'aura changé de PC et tu mettra un SSD/NVME 2* plus gros dedans.
si ton appareil le supporte et que tu peux te le payer, un disque nvme mc2 pcie 250Go est parfait (si tu peux le faire et que tu ne le fais pas tu vas vite le regretter)
A moins d'avoir un usage très exigeant sur la lecture/écriture de très gros fichiers (genre -encore une fois- montage video), la différence de perf perçue au quotidien entre un SSD SATA et un SSD PCIe est insensible. C'est en tous cas ce que je constate entre deux machines comparables à part le type de SSD.
Nicolas George
jdd , dans le message <5a830045$0$20459$, a écrit :
Tu n'es surtout pas assez soigneux quand tu t'exprimes.
pourtant je viens de vérifier et c'est bien hibernation...
Tu confirmes ce que j'écris. Relis-toi bien.
jdd , dans le message <5a830045$0$20459$426a74cc@news.free.fr>, a
écrit :
Tu n'es surtout pas assez soigneux quand tu t'exprimes.
pourtant je viens de vérifier et c'est bien hibernation...
jdd , dans le message <5a830045$0$20459$, a écrit :
Tu n'es surtout pas assez soigneux quand tu t'exprimes.
pourtant je viens de vérifier et c'est bien hibernation...
Tu confirmes ce que j'écris. Relis-toi bien.
pehache
Le 13/02/2018 à 15:19, jdd a écrit :
Le 13/02/2018 à 13:22, pehache a écrit :
Le 13/02/2018 à 13:01, jdd a écrit :
mais elle se fait le plus souvent dans l'espace de swap
Physiquement cela me parait difficile : l'espace nécessaire pour l'hibernation c'est la quantité de RAM + l'espace disque alloué au swap.
ben non
Sous Windows les fichiers de swap et d'hibernation sont clairement différents.
oui, mais il ne s'agit pas de partition. On peut sans doute, même sous Linux, ne pas mettre de swap et hiberner dans un fichier (au fait, on dit bien hiberner, pas hiverner, comme pour un ours :-)), mais c'est peu commun. J'ai 16Go de ram et 8 Go de ram
8Go de swap tu veux dire ?
et j'hiberne très bien: et d'un toute la partie der am utilisée en cache est libérée, et de deux la ram est comprimée mais ca va pour moi, peut-être pas pour d'autres (le disque vient d'un système qui avait initialement 4Go de ram)
C'est surtout que rien ne garantit que ça va marcher à tous les coups. Si tu as ouvert plein d'applis et de documents qui font que la RAM et le swap sont bien remplis (et avec peu de cache en RAM), il peut être impossible de faire rentrer 16+8Go dans les 8Go du swap, même en compressant et en virant les données en cache.
Le 13/02/2018 à 15:19, jdd a écrit :
Le 13/02/2018 à 13:22, pehache a écrit :
Le 13/02/2018 à 13:01, jdd a écrit :
mais elle se fait le plus souvent dans l'espace de swap
Physiquement cela me parait difficile : l'espace nécessaire pour
l'hibernation c'est la quantité de RAM + l'espace disque alloué au swap.
ben non
Sous Windows les fichiers de swap et d'hibernation sont clairement
différents.
oui, mais il ne s'agit pas de partition.
On peut sans doute, même sous Linux, ne pas mettre de swap et hiberner
dans un fichier (au fait, on dit bien hiberner, pas hiverner, comme pour
un ours :-)), mais c'est peu commun.
J'ai 16Go de ram et 8 Go de ram
8Go de swap tu veux dire ?
et j'hiberne très bien: et d'un toute la
partie der am utilisée en cache est libérée, et de deux la ram est
comprimée
mais ca va pour moi, peut-être pas pour d'autres (le disque vient d'un
système qui avait initialement 4Go de ram)
C'est surtout que rien ne garantit que ça va marcher à tous les coups. Si
tu as ouvert plein d'applis et de documents qui font que la RAM et le swap
sont bien remplis (et avec peu de cache en RAM), il peut être impossible
de faire rentrer 16+8Go dans les 8Go du swap, même en compressant et en
virant les données en cache.
mais elle se fait le plus souvent dans l'espace de swap
Physiquement cela me parait difficile : l'espace nécessaire pour l'hibernation c'est la quantité de RAM + l'espace disque alloué au swap.
ben non
Sous Windows les fichiers de swap et d'hibernation sont clairement différents.
oui, mais il ne s'agit pas de partition. On peut sans doute, même sous Linux, ne pas mettre de swap et hiberner dans un fichier (au fait, on dit bien hiberner, pas hiverner, comme pour un ours :-)), mais c'est peu commun. J'ai 16Go de ram et 8 Go de ram
8Go de swap tu veux dire ?
et j'hiberne très bien: et d'un toute la partie der am utilisée en cache est libérée, et de deux la ram est comprimée mais ca va pour moi, peut-être pas pour d'autres (le disque vient d'un système qui avait initialement 4Go de ram)
C'est surtout que rien ne garantit que ça va marcher à tous les coups. Si tu as ouvert plein d'applis et de documents qui font que la RAM et le swap sont bien remplis (et avec peu de cache en RAM), il peut être impossible de faire rentrer 16+8Go dans les 8Go du swap, même en compressant et en virant les données en cache.
pehache
Le 13/02/2018 à 14:34, Nicolas George a écrit :
pehache , dans le message , a écrit :
Physiquement cela me parait difficile : l'espace nécessaire pour l'hibernation c'est la quantité de RAM + l'espace disque alloué au swap.
Non, c'est la quantité UTILISÉE de mémoire virtuelle.
Qui est (au maximum) égale à la quantité de RAM + de swap, non ?
Le 13/02/2018 à 14:34, Nicolas George a écrit :
pehache , dans le message
<b0a35be95be76dd994b636a5232a4eb3ac7c646a@news.nemoweb.net>, a écrit :
Physiquement cela me parait difficile : l'espace nécessaire pour
l'hibernation c'est la quantité de RAM + l'espace disque alloué au swap.
Non, c'est la quantité UTILISÉE de mémoire virtuelle.
Qui est (au maximum) égale à la quantité de RAM + de swap, non ?
Qui est (au maximum) égale à la quantité de RAM + de swap, non ?
Et donc en général strictement inférieure. Si elle est supérieure à juste le swap, l'hibernation échoue.
Ascadix
pehache a écrit dans : <news:
Le 13/02/2018 à 15:23, jdd a écrit :
Le 13/02/2018 à 13:32, Ascadix a écrit :
Le temps que tu le crame, t'aura changé de PC et tu mettra un SSD/NVME 2* plus gros dedans.
si ton appareil le supporte et que tu peux te le payer, un disque nvme mc2 pcie 250Go est parfait (si tu peux le faire et que tu ne le fais pas tu vas vite le regretter)
A moins d'avoir un usage très exigeant sur la lecture/écriture de très gros fichiers (genre -encore une fois- montage video), la différence de perf perçue au quotidien entre un SSD SATA et un SSD PCIe est insensible. C'est en tous cas ce que je constate entre deux machines comparables à part le type de SSD.
Perso, je sens la différence, au boulot quand il commence à y avoir 4 ou 5 VM Hyper-V, AD, Exchange, XenApp, SQL, etc ... qui tournent dessus :-) Mais sinon, en mode bureautique, c'est vrai que c'est pas hyper-sensible. -- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
pehache a écrit dans
<59b54bb1b57b8fc2c18c48b3e8214e819558aaed@news.nemoweb.net>:
<news:59b54bb1b57b8fc2c18c48b3e8214e819558aaed@news.nemoweb.net>
Le 13/02/2018 à 15:23, jdd a écrit :
Le 13/02/2018 à 13:32, Ascadix a écrit :
Le temps que tu le crame, t'aura changé de PC et tu mettra un SSD/NVME
2* plus gros dedans.
si ton appareil le supporte et que tu peux te le payer, un disque nvme
mc2 pcie 250Go est parfait (si tu peux le faire et que tu ne le fais pas
tu vas vite le regretter)
A moins d'avoir un usage très exigeant sur la lecture/écriture de très
gros fichiers (genre -encore une fois- montage video), la différence de
perf perçue au quotidien entre un SSD SATA et un SSD PCIe est insensible.
C'est en tous cas ce que je constate entre deux machines comparables à
part le type de SSD.
Perso, je sens la différence, au boulot quand il commence à y avoir 4
ou 5 VM Hyper-V, AD, Exchange, XenApp, SQL, etc ... qui tournent dessus
:-)
Mais sinon, en mode bureautique, c'est vrai que c'est pas
hyper-sensible.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Le temps que tu le crame, t'aura changé de PC et tu mettra un SSD/NVME 2* plus gros dedans.
si ton appareil le supporte et que tu peux te le payer, un disque nvme mc2 pcie 250Go est parfait (si tu peux le faire et que tu ne le fais pas tu vas vite le regretter)
A moins d'avoir un usage très exigeant sur la lecture/écriture de très gros fichiers (genre -encore une fois- montage video), la différence de perf perçue au quotidien entre un SSD SATA et un SSD PCIe est insensible. C'est en tous cas ce que je constate entre deux machines comparables à part le type de SSD.
Perso, je sens la différence, au boulot quand il commence à y avoir 4 ou 5 VM Hyper-V, AD, Exchange, XenApp, SQL, etc ... qui tournent dessus :-) Mais sinon, en mode bureautique, c'est vrai que c'est pas hyper-sensible. -- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Lucas Levrel
Le 13 février 2018, à 12:12, Nicolas George a écrit :
pehache , dans le message , a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une partie du disque non partitionnée. Cette partie sert à réallouer les blocs "grillés".
Non, ça ne sert à rien.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que l'espace non partitionné n'est pas utilisé. Il contient souvent le bootloader, parfois également des données cachées exprès.
J'ai un SSD Samsung et la notice précise explicitement qu'il est conseillé de laisser de l'espace non utilisé pour améliorer le « wear-leveling » (réallocation dynamique ?). Le contrôleur ne va évidemment pas utiliser l'espace non partitionné pour remplacer des blocs grillés ; mais il compte le nombre d'écriture sur chaque bloc, et un espace non partitionné et effectivement non utilisé donnera une réserve de blocs neufs pour la réallocation de blocs « vieux » (mais pas grillés). -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Le 13 février 2018, à 12:12, Nicolas George a écrit :
pehache , dans le message
<170a8bd3c3ea663c810baf39d8e3dcc86c76e97d@news.nemoweb.net>, a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une
partie du disque non partitionnée. Cette partie sert à réallouer les
blocs "grillés".
Non, ça ne sert à rien.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que
l'espace non partitionné n'est pas utilisé. Il contient souvent le
bootloader, parfois également des données cachées exprès.
J'ai un SSD Samsung et la notice précise explicitement qu'il est conseillé
de laisser de l'espace non utilisé pour améliorer le « wear-leveling »
(réallocation dynamique ?). Le contrôleur ne va évidemment pas utiliser
l'espace non partitionné pour remplacer des blocs grillés ; mais il compte
le nombre d'écriture sur chaque bloc, et un espace non partitionné et
effectivement non utilisé donnera une réserve de blocs neufs pour la
réallocation de blocs « vieux » (mais pas grillés).
Le 13 février 2018, à 12:12, Nicolas George a écrit :
pehache , dans le message , a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une partie du disque non partitionnée. Cette partie sert à réallouer les blocs "grillés".
Non, ça ne sert à rien.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que l'espace non partitionné n'est pas utilisé. Il contient souvent le bootloader, parfois également des données cachées exprès.
J'ai un SSD Samsung et la notice précise explicitement qu'il est conseillé de laisser de l'espace non utilisé pour améliorer le « wear-leveling » (réallocation dynamique ?). Le contrôleur ne va évidemment pas utiliser l'espace non partitionné pour remplacer des blocs grillés ; mais il compte le nombre d'écriture sur chaque bloc, et un espace non partitionné et effectivement non utilisé donnera une réserve de blocs neufs pour la réallocation de blocs « vieux » (mais pas grillés). -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
pehache
Le 13/02/2018 à 22:10, Lucas Levrel a écrit :
Le 13 février 2018, à 12:12, Nicolas George a écrit :
pehache , dans le message , a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une partie du disque non partitionnée. Cette partie sert à réallouer les blocs "grillés".
Non, ça ne sert à rien.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que l'espace non partitionné n'est pas utilisé. Il contient souvent le bootloader, parfois également des données cachées exprès.
J'ai un SSD Samsung et la notice précise explicitement qu'il est conseillé de laisser de l'espace non utilisé pour améliorer le « wear-leveling » (réallocation dynamique ?).
"nivellement d'usure" je dirais.
Le contrôleur ne va évidemment pas utiliser l'espace non partitionné pour remplacer des blocs grillés ;
D'où ma réponse initiale ;)
mais il compte le nombre d'écriture sur chaque bloc, et un espace non partitionné et effectivement non utilisé donnera une réserve de blocs neufs pour la réallocation de blocs « vieux » (mais pas grillés).
Oui, mais ce qui compte c'est en fait qu'il y ait de l'espace libre sur le disque, peu importe qu'il soit dans une partition ou hors partition. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 13/02/2018 à 22:10, Lucas Levrel a écrit :
Le 13 février 2018, à 12:12, Nicolas George a écrit :
pehache , dans le message
<170a8bd3c3ea663c810baf39d8e3dcc86c76e97d@news.nemoweb.net>, a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une
partie du disque non partitionnée. Cette partie sert à réallouer les
blocs "grillés".
Non, ça ne sert à rien.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que
l'espace non partitionné n'est pas utilisé. Il contient souvent le
bootloader, parfois également des données cachées exprès.
J'ai un SSD Samsung et la notice précise explicitement qu'il est
conseillé de laisser de l'espace non utilisé pour améliorer le «
wear-leveling » (réallocation dynamique ?).
"nivellement d'usure" je dirais.
Le contrôleur ne va
évidemment pas utiliser l'espace non partitionné pour remplacer des
blocs grillés ;
D'où ma réponse initiale ;)
mais il compte le nombre d'écriture sur chaque bloc, et
un espace non partitionné et effectivement non utilisé donnera une
réserve de blocs neufs pour la réallocation de blocs « vieux » (mais pas
grillés).
Oui, mais ce qui compte c'est en fait qu'il y ait de l'espace libre sur
le disque, peu importe qu'il soit dans une partition ou hors partition.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Le 13 février 2018, à 12:12, Nicolas George a écrit :
pehache , dans le message , a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une partie du disque non partitionnée. Cette partie sert à réallouer les blocs "grillés".
Non, ça ne sert à rien.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que l'espace non partitionné n'est pas utilisé. Il contient souvent le bootloader, parfois également des données cachées exprès.
J'ai un SSD Samsung et la notice précise explicitement qu'il est conseillé de laisser de l'espace non utilisé pour améliorer le « wear-leveling » (réallocation dynamique ?).
"nivellement d'usure" je dirais.
Le contrôleur ne va évidemment pas utiliser l'espace non partitionné pour remplacer des blocs grillés ;
D'où ma réponse initiale ;)
mais il compte le nombre d'écriture sur chaque bloc, et un espace non partitionné et effectivement non utilisé donnera une réserve de blocs neufs pour la réallocation de blocs « vieux » (mais pas grillés).
Oui, mais ce qui compte c'est en fait qu'il y ait de l'espace libre sur le disque, peu importe qu'il soit dans une partition ou hors partition. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Pascal Hambourg
Le 13/02/2018 à 13:12, Nicolas George a écrit :
pehache , dans le message , a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une partie du disque non partitionnée. Cette partie sert à réallouer les blocs "grillés".
Non, ça ne sert à rien.
Comme il a été dit ça peut servir à faciliter le nivellement de l'usure et autres tâches de maintenance du contrôleur intégré, mais pas à la réallocation des blocs défectueux qui se fait à partir de blocs cachés.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que l'espace non partitionné n'est pas utilisé. Il contient souvent le bootloader, parfois également des données cachées exprès.
Il n'a pas besoin de lire la table de partition (et il ne devrait surtout pas le faire, on a vu ce qu'a donné un firmware "optimisé" pour NTFS avec les autres systèmes de fichiers) pour ça. Il sait déjà quels sont les blocs non utilisés : ce sont ceux qui n'ont jamais été écrits ou ont été TRIMés.
Le 13/02/2018 à 13:12, Nicolas George a écrit :
pehache , dans le message
<170a8bd3c3ea663c810baf39d8e3dcc86c76e97d@news.nemoweb.net>, a écrit :
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une
partie du disque non partitionnée. Cette partie sert à réallouer les
blocs "grillés".
Non, ça ne sert à rien.
Comme il a été dit ça peut servir à faciliter le nivellement de l'usure
et autres tâches de maintenance du contrôleur intégré, mais pas à la
réallocation des blocs défectueux qui se fait à partir de blocs cachés.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que
l'espace non partitionné n'est pas utilisé. Il contient souvent le
bootloader, parfois également des données cachées exprès.
Il n'a pas besoin de lire la table de partition (et il ne devrait
surtout pas le faire, on a vu ce qu'a donné un firmware "optimisé" pour
NTFS avec les autres systèmes de fichiers) pour ça. Il sait déjà quels
sont les blocs non utilisés : ce sont ceux qui n'ont jamais été écrits
ou ont été TRIMés.
Après une bonne pratique pour l'usage d'un SSD, c'est de laisser une partie du disque non partitionnée. Cette partie sert à réallouer les blocs "grillés".
Non, ça ne sert à rien.
Comme il a été dit ça peut servir à faciliter le nivellement de l'usure et autres tâches de maintenance du contrôleur intégré, mais pas à la réallocation des blocs défectueux qui se fait à partir de blocs cachés.
Je confirme : le contrôleur n'a absolument pas le droit de supposer que l'espace non partitionné n'est pas utilisé. Il contient souvent le bootloader, parfois également des données cachées exprès.
Il n'a pas besoin de lire la table de partition (et il ne devrait surtout pas le faire, on a vu ce qu'a donné un firmware "optimisé" pour NTFS avec les autres systèmes de fichiers) pour ça. Il sait déjà quels sont les blocs non utilisés : ce sont ceux qui n'ont jamais été écrits ou ont été TRIMés.
