# SSD : La documentation et les conseils (installation)

**URL:** <https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140>\
**Category:** Support Debian\
**Created:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140 "2016-02-21T21:43:27Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/1 "2016-02-21T21:43:27Z")

</div>

Bonjour aux membres du forum,

J’ai un portable Asus de la famille n73sm (n73sm-tz124v) que j’ai utilisé trois années avec Gentoo.

Je n’ai jamais réussi à bien faire fonctionner le système vidéo hybride Optimus alors je lui prévois une Jessie - qui annonce gérer ce système facilement\*.

J’ai placé un Cruxial MX100 512 GB à la place du lecteur optique.

J’ai compris qu’avec un SSD, il fallait éviter de réécrire sur les même emplacements du disque et que je n’ai pas besoin de swap.

Je dispose d’une mémoire vive de 12 GB.

Je suis à la recherche de conseils et de ressources françaises pour me faciliter l’installation et aussi pour m’éviter de faire des conneries (pour le SSD)

Je suis certain que la ressource n’est pas loin … dans une botte de foin 😉

Là où j’en suis, c’est : ne mets pas de swap et le reste va se faire bien tout seul …

Je vois aussi : [Optimiser un disque dur SSD sous Debian, Linux Mint, Ubuntu, et dérivés (dmesg.fr:~#)](http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-ssd-sous-debian-linux-mint-ubuntu-et-derives)

C’est plus ardu que je croyais mais pas impossible.

J’ai cette machine et aussi un HP Proliant n40l ([HP MicroServer N40L Wiki](http://n40l.wikia.com/wiki/HP_MicroServer_N40L_Wiki)) qui est sous Jessie depuis 3 jours ; Elle était également sous Gentoo.

Il est assez évident que j’aurai besoin à nouveau d’aide … 🙂

Merci d’avance de m’éviter les bévues et les pertes de temps

r2mi

- fr/Bumblebee " Pour résumer, c’est maintenant très simple " ; J’en reviens pas !

édition : Il va être question de “TRIMer” dans ce qui suit ; Ce terme Franglais n’étant pas forcément compréhensible ni même très agréable, je vous indique qu’il s’agit de “libérer de toute occupation” des cellules d’un disque SSD.

---

<div class="post-metadata">

**Author:** ![anon60101063](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@anon60101063](https://www.debian-fr.org/u/anon60101063)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/2 "2016-02-21T21:43:27Z")

</div>

La doc’ que tu mets en lien est parfaite, je ne vois pas le problème…Pourquoi aurais-tu besoin d’aide ? 🙂

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/3 "2016-02-21T21:43:28Z")

</div>

Ta réponse Stuffboxinou m’enlève bien des doutes, je t’en remercie.

J’ai besoin d’aide parce que je pratique en solitaire et que je n’ai pas de veille professionnelle.

Je re-débute avec Debian et j’ai envie d’avancer dans le respect de la distro ; pas n’importe comment.

Et avoir quelques échanges ne me fait pas de mal non plus 😉

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/4 "2016-02-21T21:43:28Z")

</div>

> [@r2mi](#):
>
> avec un SSD, il fallait éviter de réécrire sur les même emplacements du disque

Sans importance. Les contrôleurs intégrés dans les SSD actuels ont des systèmes de nivellement de l’usure. Lorsqu’on réécrit un bloc logique souvent, il est physiquement déplacé ailleurs. Ce ne sont pas des clés USB.

> [@r2mi](#):
>
> je n’ai pas besoin de swap

Donc tu ne comptes pas utiliser l’hibernation.

Laisser de l’espace libre facilite le nivellement de l’usure et améliore les performances en écriture.  
Activer le TRIM soit «&nbsp;en ligne&nbsp;» (option de montage «&nbsp;discard&nbsp;» dans fstab) ou hors ligne (commande fstrim) également.  
Utiliser des tmpfs pour les fichiers temporaires quand on a beaucoup de RAM est une bonne idée.

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/5 "2016-02-21T21:43:28Z")

</div>

Merci PascalHambourg

---

<div class="post-metadata">

**Author:** ![anon60101063](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@anon60101063](https://www.debian-fr.org/u/anon60101063)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/6 "2016-02-21T21:43:28Z")

</div>

Si ton SSD est tout neuf, tu pourras, de temps à autre, utiliser cette commande :

```nohighlight
tune2fs -l /dev/sda1 | grep 'Lifetime writes:'

```

Il faudra remplacer /dev/sda1 par tes partitions. Tu pourras les voir avec la commande :

```nohighlight
fdisk -l

```

Ça te donnera la quantité que tu as déjà écrite sur le SSD depuis l’installation. On estime que chaque cellule peut être écrite environ 100000 fois. Du coup, avec un calcul simple, tu pourras “estimer”, selon la taille de ton disque, son “pourcentage de vie”.

Le mien, par exemple, au bout de 3 ans, en est à 12% d’écriture. J’ai encore une vingtaine d’années devant moi, donc. 😛

Ce n’est bien sûr qu’un diagnostic un peu grossier, une sorte d’estimation de Fermi, mais ça donne une idée pas trop fausse ! 🙂

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/7 "2016-02-21T21:43:37Z")

</div>

Bonjour,

J’ai donc placé un :

```nohighlight
fstrim -v /

```

dans mon /etc/rc.local comme indiqué dans le lien de mon premier message.  
L’option de montage “discard” dans fstab est-t’elle plus intéressante pour l’envoi des commandes fréquentes ?

J’ai aussi, d’après ce lien, placé :

```nohighlight
vm.swappiness=1

```

Dans mon /etc/sysctl.conf

Et pour les espaces en mémoire vive, j’ai utilisé le fichier de configuration /etc/default/tmpfs où ça se résume à :

```nohighlight
RAMLOCK=yes
RAMSHM=yes
RAMTMP=yes
TMPFS_SIZE=20%VM
RUN_SIZE=10%
LOCK_SIZE=5242880 # 5MiB
#SHM_SIZE=
TMP_SIZE=524288000
#TMP_OVERFLOW_LIMIT=1024

```

Je n’avais aucune idée de la valeur à mettre pour TMP\_SIZE alors j’ai centuplé celle de LOCK\_SIZE, soit 500MiB  
Et en voyant,

```nohighlight
root@n73sm:~# df -ah
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
rootfs - - - - /
sysfs 0 0 0 - /sys
proc 0 0 0 - /proc
udev 10M 0 10M 0% /dev
devpts 0 0 0 - /dev/pts
tmpfs 2,4G 8,7M 2,4G 1% /run
/dev/sdc3 413G 1,8G 390G 1% /
securityfs 0 0 0 - /sys/kernel/security
tmpfs 5,9G 0 5,9G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 5,9G 0 5,9G 0% /sys/fs/cgroup
cgroup 0 0 0 - /sys/fs/cgroup/systemd
pstore 0 0 0 - /sys/fs/pstore
cgroup 0 0 0 - /sys/fs/cgroup/cpuset
cgroup 0 0 0 - /sys/fs/cgroup/cpu,cpuacct
cgroup 0 0 0 - /sys/fs/cgroup/devices
cgroup 0 0 0 - /sys/fs/cgroup/freezer
cgroup 0 0 0 - /sys/fs/cgroup/net_cls,net_prio
cgroup 0 0 0 - /sys/fs/cgroup/blkio
cgroup 0 0 0 - /sys/fs/cgroup/perf_event
systemd-1 - - - - /proc/sys/fs/binfmt_misc
mqueue 0 0 0 - /dev/mqueue
debugfs 0 0 0 - /sys/kernel/debug
hugetlbfs 0 0 0 - /dev/hugepages
/dev/md0 917G 72M 908G 1% /home
rpc_pipefs 0 0 0 - /run/rpc_pipefs
binfmt_misc 0 0 0 - /proc/sys/fs/binfmt_misc

```

Je me demande si mon RAMTMP est fonctionnel ? TMPFS\_SIZE=20%VM prendrait-t’il la priorité sur les autres paramètres ? Merci  
Il me semble aussi que l’espace alloué à /run est très exagéré.

La commande indiquée par Stuffboxinou pour avoir une estimation de viabilité du SSD me renvoie une valeur que je n’interprète pas (le GB) :

```nohighlight
root@n73sm:~# tune2fs -l /dev/sdc3 | grep 'Lifetime writes:'
Lifetime writes: 1237 GB

```

J’ai placé une partition de type 83 non formatée de 50 GB sur le SSD  
correction : j’ai laissé un espace non alloué de 50 GB sur le SSD

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 21, 2016, 9:43 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/8 "2016-02-21T21:43:37Z")

</div>

> [@r2mi](#):
>
> L’option de montage «&nbsp;discard&nbsp;» dans fstab est-t’elle plus intéressante pour l’envoi des commandes fréquentes ?

Il y a eu de nombreux débats sur ce point, et actuellement fstrim semble préféré.  
En effet la commande TRIM originelle du SATA est «&nbsp;bloquante&nbsp;» (non queueable), ce qui signifie qu’aucune opération de lecture ou d’écriture ne peut avoir lieu pendant son exécution. Comme elle peut prendre un certain temps, c’est assez gênant si elle se produit au mauvais moment. Une nouvelle commande non bloquante (queueable) a été définie mais elle n’est pas forcément implémentée par tous les SSD, surtout les plus anciens.

---

<div class="post-metadata">

**Author:** ![Eric75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eric75/32/4483_2.png) [@Eric75](https://www.debian-fr.org/u/Eric75)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/9 "2016-02-21T21:44:05Z")

</div>

J’en profite pour poser une question à laquelle je n’ai jamais eu de réponse : on voit très souvent l’option `noatime` positionnée dans un /etc/fstab mais aussi (un peu moins souvent par contre) en plus de cette dernière, l’option `nodiratime`.

Est-ce un oubli, ou est-ce parce que l’option `noatime` engloberait les inodes des fichiers et des répertoires, contrairement à `nodiratime` qui serait juste pour les inodes des répertoires ? (du coup, `nodiratime` serait redondant si l’option `noatime` est déjà positionnée ?)

Le man mount n’est pas super explicite à ce sujet :

> [@](#):
>
> ```plaintext
> noatime
> Do not update inode access times on this filesystem (e.g, for faster access on the news spool to speed up news servers).
> 
> ```

et

> [@](#):
>
> ```plaintext
> nodiratime
> Do not update directory inode access times on this filesystem.
> 
> ```

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/10 "2016-02-21T21:44:05Z")

</div>

Bonjour Eric75

Tu as tout à fait raison ; ton raisonnement est juste.

J’ai eu lecture du (f) manuel précis indiquant cette redondance ; mais où et quand, ça, cela m’échappe ; Mais ce n’est jamais bien loin amha

édition : [http://lwn.net/Articles/244941/](http://lwn.net/Articles/244941/)

> [@](#):
>
> noatime is a superset of nodiratime, btw.

Il faut être quand même certain que des sources sont un grand arbre et que nous sommes dans une forêt …

Alors de là à dire que cette redondance «&nbsp;englobante&nbsp;» s’applique partout et tout le temps, là, je me retire 😉

Merci pour ta contribution 🙂

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/11 "2016-02-21T21:44:06Z")

</div>

A noter que l’option **`relatime`** , qui est désormais l’option par défaut, est un bon compromis entre la limitation des écritures (pour la durée de vie des SSD) et le besoin de certains logiciels comme **`mutt`** de savoir si un fichier a été lu depuis sa dernière modification, ce que ne permet pas **`noatime`**. L’option **`nodiratime`** permettrait alors de ne pas appliquer le comportement par défaut de **`relatime`** aux répertoires et ainsi d’économiser quelques écritures.

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/12 "2016-02-21T21:44:07Z")

</div>

J’ai adopté le bon compromis pour mon SSD tel qu’indiqué par PascalHambourg. J’ai ajouté “nodiratime” pour la petite économie ; pour / : ma partition\* du SDD.

nota béta, par expérience et dans ce contexte, ne confondez pas “relatime” avec “realtime” ; Vous seriez bon pour un mode de récupération.

Comme l’indique PascalHambourg, “relatime” est par défaut mais j’ai préféré surcharger.

- avec également un swap équivalent à la RAM

---

<div class="post-metadata">

**Author:** ![Eric75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eric75/32/4483_2.png) [@Eric75](https://www.debian-fr.org/u/Eric75)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/13 "2016-02-21T21:44:07Z")

</div>

Merci r2mi et PascalHambourg pour vos réponses : je sais maintenant quoi mettre dans mon **`/etc/fstab`** , cool !

Concernant la commande **`fstrim -v /point-de-montage`** , je ne suis pas sûr que ce soit si judicieux que cela de l’ajouter dans **`/etc/rc.local`** : d’après le man trouvé [ici](http://man7.org/linux/man-pages/man8/fstrim.8.html), on peut lire :

> [@](#):
>
> Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices.  
> For most desktop and server systems the sufficient trimming frequency is once a week.

Et effectivement :

- si on est sur un serveur, celui-ci n’ayant pas vocation à redémarrer souvent, le **`fstrim`** ne sera réalisé que tous les 36 du mois,
- inversement, si on se trouve sur une workstation, qui a plus de chance d’être éteinte souvent voire tous les soirs, on risque d’avoir trop de **`fstrim`**.

Je ne pense pas avoir un «&nbsp;poor-quality SSD device&nbsp;» mais bon…  
Ne serait-il pas mieux de faire un **`cron`** hebdomadaire de cette commande ?

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/14 "2016-02-21T21:44:07Z")

</div>

@Eric75

> [@](#):
>
> Je ne pense pas avoir un «&nbsp;poor-quality SSD device&nbsp;» mais bon…

De quel SSD disposes-tu ?

Perso, mon MX100 est garanti 3 ans ; Je présume que cela indique une haute qualité (?)

J’ai déjà un :

`root@n73sm:~# tune2fs -l /dev/sdc3 | grep 'Lifetime writes:'
Lifetime writes: 8097 GB`  
Que je n’arrive pas à interpréter …

> [@](#):
>
> Ne serait-il pas mieux de faire un cron hebdomadaire de cette commande ?

D’après ton argumentaire, je trouve la suggestion intéressante…

Je décide de l’appliquer sur le champ. En laissant également la commande fstrim de mon rc.local  
Je précède mon entrée crontab d’un «&nbsp;nice -n +15&nbsp;» en me disant " pour laisser le champ libre "

J’ai une entrée crontab :

```auto
0	0	*	*	0	/usr/bin/nice -n +15 /bin/date >> /var/log/fstrim-v.log && /sbin/fstrim -v / >> /var/log/fstrim-v.log
```

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/15 "2016-02-21T21:44:09Z")

</div>

> [@r2mi](#):
>
> ```plaintext
> root@n73sm:~# tune2fs -l /dev/sdc3 | grep 'Lifetime writes:'
> Lifetime writes: 8097 GB
> 
> ```
> 
> Que je n’arrive pas à interpréter

Cele indique juste que ~8 To ont été écrits sur le système de fichiers contenu dans la partition /dev/sdc3. Je doute que ce soit un indicateur très fiable de l’usure du SSD. Pour cela, je consulterais plutôt vers les attributs SMART.

```plaintext
smartctl -A /dev/sdc

```

> [@r2mi](#):
>
> Je précède mon entrée crontab d’un «&nbsp;nice -n +15&nbsp;» en me disant " pour laisser le champ libre "

Pas sûr que ça serve à quelque chose car c’est l’exécution de la commande ATA TRIM elle-même par le disque qui est susceptible de dégrader les performances du disque, surtout si elle est «&nbsp;non queued&nbsp;».

---

<div class="post-metadata">

**Author:** ![anon60101063](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@anon60101063](https://www.debian-fr.org/u/anon60101063)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/16 "2016-02-21T21:44:12Z")

</div>

Ce n’est pas un indicateur très fiable, c’est un ordre d’idée qui est à mettre en relation avec la moyenne d’écritures possibles sur une cellule de SSD.

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/17 "2016-02-21T21:44:13Z")

</div>

> [@Stuffboxinou](#):
>
> Ce n’est pas un indicateur très fiable, c’est un ordre d’idée qui est à mettre en relation avec la moyenne d’écritures possibles sur une cellule de SSD.

Comment fais-tu donc Stuffboxinou pour mettre en relation une quantité écrite globale avec le fameux 100,000 d’écriture pour une cellule ?

Et je vois avec «&nbsp;smartctl&nbsp;» pour ce propos ;

```plaintext

root@n73sm:~# smartctl -a /dev/sdc3
...
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
202 Percent_Lifetime_Used 0x0031 100 100 000 Pre-fail Offline - 0
...

```

> [@Les Numériques : Peut-on surveiller l'état de son SSD ?](#):
>
> [http://www.lesnumeriques.com/ssd/ssd-tout-savoir-tout-comprendre-a1630.html](http://www.lesnumeriques.com/ssd/ssd-tout-savoir-tout-comprendre-a1630.html)
> 
> … on peut accéder aux données SMART de son SSD et prendre connaissance, entre autres, de son degré d’usure. Cela peut prendre la forme d’un indice qui démarre à 100 et finit en fin de vie à 1, comme sur les SSD en SandForce ([…] Situation de courbe de vie), ou d’un indice qui part de 0 et finit à 100 comme sur un Crucial M4 ([…] Pourcentage de la durée de vie nominale utilisée). Avec toutefois cet inconvénient que cet indice est estimé par le constructeur. Néanmoins, il est indicatif et utile.  
> …  
> D’autres informations sont intéressantes… Certains SSD vont remonter […] le nombre moyen de cycles d’écriture des cellules, mais aussi les erreurs intervenues en lecture, en écriture, les cellules flash ré-allouées … Ces […] données sont à surveiller si elles se mettent à augmenter ! Il est donc recommandé de contrôler ces infos SMART de temps en temps.

> [@PascalHambourg](#):
>
> Une nouvelle commande non bloquante (queueable) a été définie mais elle n’est pas forcément implémentée par tous les SSD, surtout les plus anciens.

Peut-t’on trouver cette indication (l’implémentation non bloquante de la commande fstrim ou de l’option discard) dans les caractéristiques détaillées d’un disque SSD ou alors avec l’outil smartctl ou avec un autre ? Comment s’appelle-t’elle ?

---

<div class="post-metadata">

**Author:** ![SylvainMuller](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/58956e/32.png) [@SylvainMuller](https://www.debian-fr.org/u/SylvainMuller)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/18 "2016-02-21T21:44:20Z")

</div>

Pour suivre, (de très près d’ailleurs 😊 ).

Merci de ton questionnement r2mi.

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/19 "2016-02-21T21:44:21Z")

</div>

Merci SylvainMuller, c’est gentil à toi

> [@Understanding SSD System Requirements](#):
>
> [http://www.samsung.com/global/business/semiconductor/minisite/SSD/downloads/document/02\_Understanding\_SSD\_System\_Requirements.pdf](http://www.samsung.com/global/business/semiconductor/minisite/SSD/downloads/document/02_Understanding_SSD_System_Requirements.pdf)
> 
> SATA 3.0
> 
> Released in 2009, SATA 3.0, also known as SATA 6Gb/s, is the third generation of the SATA specification. It is capable of communicating at up to 600MB/s, with overhead taken into account. In addition to its speed improvements, this revision also introduces NCQ management, improved power management features, and queued TRIM support (allowing TRIM commands to be queued with I/O requests, which was not possible on earlier implementations). While it is currently capable of supporting the massive speeds of today’s SSDs, it is already being outpaced as SSD technology advances. This is the standard that most modern SSDs are built to support, although they are backwards compatible with the earlier standards as well

Nous apprenons ici que le disque SSD Sata 3.0 donne «&nbsp;queued TRIM support allowing TRIM commands to be queued with I/O requests&nbsp;»

Donc pour ces matériels les plus récents ça donne la possibilité, sans équivoque j’imagine, de placer l’option «&nbsp;discard&nbsp;» pour le(s) montage(s) SSD

Mais cela dépend-t’il seulement du disque SSD à la norme SATA 3.0 ou bien au mode de fonctionnement effectif SATA 3.0 ?

Il y a différentes version du contrôleur matériel AHCI ;

Mon Asus est équipé d’un contrôleur AHCI Intel 1.0 et dont sa version précise supporte le 300 MB/s théorique ;

```plaintext
root@n73sm:~# lspci -v -s 00:1f.2
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 05) (prog-if 01 [AHCI 1.0])
	Subsystem: ASUSTeK Computer Inc. Device 11d7
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 41
	I/O ports at e0b0 [size=8]
	I/O ports at e0a0 [size=4]
	I/O ports at e090 [size=8]
	I/O ports at e080 [size=4]
	I/O ports at e060 [size=32]
	Memory at df006000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [70] Power Management version 3
	Capabilities: [a8] SATA HBA v1.0
	Capabilities: [b0] PCI Advanced Features
	Kernel driver in use: ahci

```

Voyez aussi les spécifications des révisions AHCI Intel :

[http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev095.html](http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev095.html)  
[http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1\_0.html](http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1_0.html)  
[http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1\_1.html](http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1_1.html)  
[http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1\_2.html](http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1_2.html)  
[http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1\_3.html](http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1_3.html)  
[http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1-3-1.html](http://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1-3-1.html)

Une question reste posée pour les machines équipées de contrôleurs AHCI «&nbsp;anciens&nbsp;» et d’un SSD SATA 3.0 :

Comment vérifier la prise en charge du support TRIM évoqué ?

> [@Verify\_TRIM\_Support](#):
>
> [https://wiki.archlinux.org/index.php/Solid\_State\_Drives#Verify\_TRIM\_Support](https://wiki.archlinux.org/index.php/Solid_State_Drives#Verify_TRIM_Support)
> 
> Verify TRIM Support
> 
> ```plaintext
> # hdparm -I /dev/sda | grep TRIM
> * Data Set Management TRIM supported (limit 1 block)
> 
> ```
> 
> Note that there are different types of TRIM support defined by the specification. Hence, the output may differ depending what the drive supports. See [https://en.wikipedia.org/wiki/Trim\_(computing)#ATA](https://en.wikipedia.org/wiki/Trim_(computing)#ATA) for more information.

```plaintext
root@n73sm:~# hdparm -I /dev/sdc | grep TRIM
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM

```

Je viens de trouver comment prouver le fonctionnement de l’option «&nbsp;discard&nbsp;» de fstab ; Cela ne prouve pas encore, je crois, que les commandes soient mises en attente (queued) ; Je ne sais pas.

C’est facile à faire et c’est rapide : [Alex Nedoboi - SSD and Linux. Enable TRIM and check if it works](https://nedoboi.wordpress.com/2011/11/12/tiny-tips-ssd-and-linux-enable-trim-and-check-if-it-works/)

Je ne me suis attaché qu’à la partie pour vérifier ; Dans mon cas, l’option «&nbsp;discard&nbsp;» fonctionne.

rappel : c’est soit un «&nbsp;fstrim -v /&nbsp;» dans /etc/rc.local (et/ou éventuellement une entrée crontab - comme l’indique intelligemment Eric75) OU BIEN l’option «&nbsp;discard&nbsp;» pour le ou les montages d’une ou plusieurs partition(s) du SSD ; Je pense qu’il ne faut pas mettre les deux façons. Pour l’option de montage «&nbsp;discard&nbsp;» il faut vérifier si ça fonctionne avec le lien ci-dessus et suivant, utiliser la première façon (fstrim) dans le cas contraire.

édition : j’ai lu des fstab avec l’option «&nbsp;discard&nbsp;» pour le swap ; je l’ai moi-même appliqué.

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Février 21, 2016, 9:44 UTC](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140/20 "2016-02-21T21:44:38Z")

</div>

> [@r2mi](#):
>
> J’ai placé une partition de type 83 non formatée de 50 GB sur le SSD  
> correction : j’ai laissé un espace non alloué de 50 GB sur le SSD

> [@dmesg.fr:~# display message](#):
>
> [http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-ssd-sous-debian-linux-mint-ubuntu-et-derives](http://www.dmesg.fr/gestion-hardware/144-optimiser-un-disque-dur-ssd-sous-debian-linux-mint-ubuntu-et-derives)
> 
> créez une partition supplémentaire vide de l’ordre de 5 à 15 % de la capacité totale du disque. N’utilisez pas cette partition.

Je trouve que ce n’est pas assez clair ;

Faut-t’il créer une partition de type Linux sans la formater d’aucune manière ou laisser un espace non-alloué ; La citation indiquerai la première façon. Je me pose quand même encore la question.

Secondo, cet ordre de 5 à 15% est grand et nous n’avons aucune indication du comment et du pourquoi de la proportion à choisir…

Il y aurait-t’il un minima en GB ? Il y aurait-t’il un maxima suffisant ?

[Page suivante](https://www.debian-fr.org/t/ssd-la-documentation-et-les-conseils-installation/66140.md?page=2)
