Installation sur un SSD

Le Sat, 16 Jan 2016 23:31:40 +0100,
Benoit B <benoitlst@gmail.com> a écrit :

Bonjour,

Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
A l'installation ?
Configuration (moins loguer, écritures sur le SWAP) ?

Merci d'avance

--
Benoit

bonjour,

voici un tuto presque complet ayant trait à la question :

http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-ssd-sous-debian-linux-mint-ubuntu-et-derives

https://wiki.debian.org/SSDOptimization
https://wiki.debian.org/SSD%20Installation

slt
bernard

Le 16/01/2016 23:31, Benoit B a écrit :

Bonjour,

Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
A l'installation ?
Configuration (moins loguer, écritures sur le SWAP) ?

en ce qui me concerne je me refuse à ce genre de chose. Je compte sur
les outils d'installation pour le faire ou sur la garantie.

tous les ssd en ce moment sont garantis trois ans, et si je regarde ce
que j'ai acheté trois ans en arrière, si les miens tombent en panne plus
tard, je ne voudrais pas remettre les même (j'ai déjà deux 120Go, un
250Ggo et un 480Go :-))

jdd

Le 16/01/2016 23:31, Benoit B a écrit :

Bonjour,

Y a-t-il quelque chose de particulier à faire pour utiliser un SSD ?
A l'installation ?
Configuration (moins loguer, écritures sur le SWAP) ?

Merci d'avance

--
Benoit

Bonjour,

J'ai plusieurs systèmes sur des SSD depuis 3 ou 4 ans maintenant, pas de choses
particulières mise à part des trucs très lights :
- les options "discard,noatime,nodiratime" sur les montages "utilisateur" (home directory),
- le répertoire /tmp monté en tmpfs pour les machines de 8Go de mémoire ou plus pour
éviter des écritures inutiles.

Les SSD sont très bien gérés par le système.

En général, ils sont garantie 3 ans dans une utilisation assez important (écriture de + de
20% du disque par jour soit une 3-4 écriture complète du disque / mois), ceci n'arrive pas
en pratique sur des ordinateurs de bureau...

Si tu as un 2eme disque à plateau classique, tu peux mettre /tmp /home /var dessus, mais
tu n'auras pas un amélioration aussi spectaculaire des performances...

Mes 2 cents...

Mourad

--047d7bf10afeb21e2c05298701e6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

Merci pour cette réponse avec un lien si précis.

Le 16 janvier 2016 à 23:54, Bernard Schoenacker bonjour,

voici un tuto presque complet ayant trait à la question :


http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-ssd-sous -debian-linux-mint-ubuntu-et-derives

https://wiki.debian.org/SSDOptimization

Pas de bol ! :(
https://wiki.debian.org/SSDOptimization#WARNING

Pour mon Samsung SSD 850 EVO

/* devices that don't properly handle queued TRIM commands */

{ "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },


https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/driver s/ata/libata-core.c#n4268

Cela veut-il dire que je ne vais pas pouvoir activer la commande TRIM (
*Discard)* avec ce modèle de disque ? :(

Merci d'avane.

Benoit

--047d7bf10afeb21e2c05298701e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div style="">Bonjour,</div><div style=""><br></div><d iv style="">Merci pour cette réponse avec un lien si précis.</d iv><div style=""><br></div>Le 16 janvier 2016 à 23:54, Bernard Schoe nacker bonjour,<div class="gmail_extra"><div class="gmail_quote"><block quote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-w idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding -left:1ex">
<br>
voici un tuto presque complet ayant trait à la question :<br>
<br>
<a href="http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur -ssd-sous-debian-linux-mint-ubuntu-et-derives" rel="noreferrer" target= "_blank">http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-s sd-sous-debian-linux-mint-ubuntu-et-derives</a><br>
<br>
<a href="https://wiki.debian.org/SSDOptimization" rel="noreferrer" targ et="_blank">https://wiki.debian.org/SSDOptimization</a></blockquote><div> <br></div><div style="">Pas de bol ! :(</div><div style=""><a href="h ttps://wiki.debian.org/SSDOptimization#WARNING">https://wiki.debian.org/SSD Optimization#WARNING</a></div><div style=""><br></div><div style="">Pou r mon <span style="color:rgb(255,0,0);font-size:13px">Samsung SSD 85 0 EVO</span></div><div style=""><pre style="padding:0px;margin-top:0px; margin-bottom:0px;color:rgb(0,0,0);font-size:13px"><code><span class="" s tyle="color:rgb(131,129,131);font-style:italic">/* devices that don&#39;t properly handle queued TRIM commands */</span></code></pre><pre style="p adding:0px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:13px "><code><span class="" style="color:rgb(131,129,131);font-style:italic" ><pre style="padding:0px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0 );font-style:normal"><code> <span class="">{</span> <span class="" styl e="color:rgb(255,0,0)">&quot;Samsung SSD 8*&quot;</span><span class=""> ,</span> NULL<span class="">,</span> ATA_HORKAGE_NO_NCQ_TRIM <span class ="">|</span>
ATA_HORKAGE_ZERO_AFTER_TRIM<span class="">, },</span></code></pre>< pre style="padding:0px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0); font-style:normal"><code><span class=""><br></span></code></pre></span></ code></pre></div><div style=""><a href="https://git.kernel.org/cgit/lin ux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4268">http s://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/at a/libata-core.c#n4268</a><br></div><div style=""><br></div><div style=" ">Cela veut-il dire que je ne vais pas pouvoir activer la commande TRIM (<b style="font-size:13px;margin:0px;padding:0px;border:0px;outline:0px;back ground-color:rgb(254,254,254);color:rgb(0,0,0);font-family:&#39;Lucida Gran de&#39;,Arial,&#39;DejaVu Sans&#39;,Verdana,sans-serif;line-height:19.20000 0762939453px">Discard)</b> avec ce modèle de disque ? :(</div><di v style=""><br></div><div style="">Merci d&#39;avane.</div><div style =""><br></div><div style="">Benoit</div><div style=""><br></div></div ></div></div>

--047d7bf10afeb21e2c05298701e6--

Le 17 janvier 2016 à 13:36, C. Mourad Jaber <ml@nativobject.net> a à ©crit :

Bonjour,

J'ai plusieurs systèmes sur des SSD depuis 3 ou 4 ans maintenant, pa s de choses particulières mise à part des trucs très lights :
- les options "discard,noatime,nodiratime" sur les montages "utilisateur " (home directory),
- le répertoire /tmp monté en tmpfs pour les machines de 8Go d e mémoire ou plus pour éviter des écritures inutiles.

Les SSD sont très bien gérés par le système.

Et pour l'option "discard" avec mon disque(Samsung SSD 8*) quelqu'un
as des infos ?
https://wiki.debian.org/SSDOptimization#WARNING

J'ai peur d'avoir fais un mauvais choix...

En général, ils sont garantie 3 ans dans une utilisation assez important (écriture de + de 20% du disque par jour soit une 3-4 é criture complète du disque / mois), ceci n'arrive pas en pratique sur des ordinateurs de bureau...

Je devrai peut-être me rabattre là dessus ?

Si tu as un 2eme disque à plateau classique, tu peux mettre /tmp /ho me /var dessus, mais tu n'auras pas un amélioration aussi spectaculair e des performances...

Non c'est un portable, une seule place et pas de M2 pour laisser un
disque à plateau classique.

Merci d'avance.

--
Benoit

Benoit B a écrit :

Pas de bol ! :(
https://wiki.debian.org/SSDOptimization#WARNING

Pour mon Samsung SSD 850 EVO

/* devices that don't properly handle queued TRIM commands */

{ "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },


https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4268

Cela veut-il dire que je ne vais pas pouvoir activer la commande TRIM (
*Discard)* avec ce modèle de disque ? :(

Non, sauf erreur ça veut dire que lors de l'effacement d'un fichier
l'option "discard" ne pourra pas utiliser la nouvelle commande TRIM
"queued" mais seulement l'ancienne commande TRIM "non queued", qui a
pour inconvénient d'interrompre les opérations de lecture/écriture en
cours et d'empêcher toute nouvelle opération avant la fin de son
exécution, qui peut être longue. C'est pourquoi certains recommandent de
ne pas utiliser l'option de montage "discard" mais d'effectuer un TRIM
périodique avec la commande "fstrim".

Bonjour,

C. Mourad Jaber a écrit :

- les options "discard,noatime,nodiratime" sur les montages
"utilisateur" (home directory),

Pourquoi limiter ces options à /home ?

L'option noatime implique l'option nodiratime. Préciser la seconde est
donc inutile quand on indique la première. Depuis la version 2.6.30, le
noyau Linux ne monte pas par défaut les partitions avec l'option
« atime » mais avec l'option « relatime » (cf. /etc/mtab), ce qui ménage
la chèvre et le chou.

En outre, à ma connaissance, l'option discard a plutôt un effet négatif
sur les performances. Cf. le point 3 de l'article ci-dessous :

http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Je lui préfère donc, comme cela est préconisé dans l'article, un petit
« /sbin/fstrim / » lancé via cron.

- 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/

L'avantage du tmpfs sur les ramdisks traditionnels est qu'il ne consomme
que la mémoire nécessaire avec un plafond fixé à 50 % de la mémoire vive
disponible. Or, l'expérience montre que la plupart du temps, le
répertoire /tmp contient moins de quelques dizaines de Mo de données,
même sur les serveurs multi-utilisateurs.

Si tu as un 2eme disque à plateau classique, tu peux mettre /tmp /home
/var dessus, mais tu n'auras pas un amélioration aussi spectaculaire
des performances...

Monter les répertoires /tmp et /var sur un disque à plateau va en effet
pénaliser le système. Pour /home, je suis persuadé que l'impact ne se
perçoit pas au niveau utilisateur (en tout cas, c'est mon ressenti
personnel).

Pour ma part, j'utilise un disque dur à plateau pour monter les
répertoires /home et /var/log :

- /home ne contient que des fichiers de données et si l'on considère les
utilisations les plus courantes, je ne vois pas ce qu'un SSD apporte.
Un SSD n'est pertinent que lorsque la rapidité des entrées/sorties
fait la performance d'une application (chargement des binaires,
compilation, base de données, etc.). Pour lire un fichier MP3 ou DIVX
ou surfer sur le net, le SSD est superflu.

- /var/log contient des fichiers de logs qui sont le plus souvent
l'œuvre de syslog, démon asynchrone qui ne pénalise pas les
applications qui lui transmettent les logs.

Ceci étant, j'ai opté pour cette configuration à l'époque où les disques
SSD coûtaient un bras et où je m'étais contenté d'un petit SSD de 64 Go.
L'année dernière, j'ai remplacé le disque à plateau d'un portable par un
disque SSD de 240 Go, cela suffit à mon bonheur.

Sébastien

--
Sébastien Dinot, sebastien.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

On Sunday 17 January 2016 13:36:46 C. Mourad Jaber wrote:

....
Les SSD sont très bien gérés par le système.

sauf lorsqu'ils tombent en rade, les SSD n'apprécient guère
trop d'écritures.

André

Bonjour,

On 17/01/2016 14:21, Sébastien Dinot wrote:

En outre, à ma connaissance, l'option discard a plutôt un effet négatif
sur les performances. Cf. le point 3 de l'article ci-dessous :

http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Je lui préfère donc, comme cela est préconisé dans l'article, un petit
« /sbin/fstrim / » lancé via cron.

Merci pour ces infos mais du coup j'aurais des questions sur discard car en
fait je ne pige pas trop l'intérêt de option ni même du /sbin/fstrim. Dans
le lien que tu donnes, on peut lire au tout début « NAND flash memory that
make SSD cannot overwrite existing data ».

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 et à un moment donné
je ne pourrai tout simplement plus écrire dessus (bien que le filesystem, lui,
ne soit pas à 100%) ? Auquel cas je trouverai un peu vache.

Personnellement, j'aurais plutôt pensé que le SSD fait le trim lui-même tout
seul comme un grand, quand ça l'arrange. Je me trompe ? Ou alors ce n'est vrai
que pour des SSD d'une certaine qualité ?

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.

Bref, si vous avez des explications sur tout ça, je serais vraiment très intéressé
car j'ai personnellement des serveurs (pas beaucoup) qui utilisent des SSD et
j'avoue que je ne me suis jamais préoccupé de cette option discard et/ou du fstrim
(pour info les SSD sont des Intel Series 3710 200GB).

Merci d'avance pour vos lumières (j'espère ne pas trop sortir du sujet de ce fil).

--
François Lafont

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
et à un moment donné je ne pourrai tout simplement plus écrire dessus
(bien que le filesystem, lui, ne soit pas à 100%) ?

Je ne suis nullement un spécialiste de la question mais ma compréhension
du fonctionnement de la commande TRIM est qu'elle marque les blocs
disponibles en réinitialisant au passage leur contenu.

Si on ne l'exécute pas de temps à autres, d'une part les performances du
SSD se dégradent petit à petit (j'ai pu le constater avant de découvrir
cette commande) et d'autre part, lorsque le contrôleur fini par avoir
besoin d'espace, il doit se livrer à de coûteux cycles de
lecture/effacement/écriture.

Personnellement, j'aurais plutôt pensé que le SSD fait le trim
lui-même tout seul comme un grand, quand ça l'arrange. Je me trompe ?
Ou alors ce n'est vrai que pour des SSD d'une certaine qualité ?

Si j'ai là encore bien compris le nœud du problème, le contrôleur SSD
n'a pas plus d'idée de la signification du contenu des blocs que le
contrôleur RAM n'a d'idée du contenu des blocs de mémoire vive. Du coup,
il ne peut déterminer lui-même quels sont les blocs libres, tout comme
le contrôleur de mémoire vive ne peut pas détecter qu'un bloc réservé
par une application n'est plus utilisé par cette application et décider
de réutiliser ce bloc. Dans les deux cas, c'est au système
d'exploitation d'agir car c'est à son niveau que la donnée prend son
sens technique et devient une information.

Sébastien

--
Sébastien Dinot, sebastien.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !