SSD : La documentation et les conseils (installation)

Support Debian
#1

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 :wink:

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:~#)

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

J’ai cette machine et aussi un HP Proliant n40l (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 … :slightly_smiling:

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.

Nouveau PC Portable - Lenovo Legion Y530-15ICH
#2

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

#3

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 :wink:

#4

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.

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 “en ligne” (option de montage “discard” 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.

1 J'aime
#5

Merci PascalHambourg

#6

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

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

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

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. :stuck_out_tongue:

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 ! :slight_smile:

1 J'aime
#7

Bonjour,

J’ai donc placé un :

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é :

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 à :

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,

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) :

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

#8

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 “bloquante” (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.

1 J'aime
#9

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 :

et

#10

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/

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 “englobante” s’applique partout et tout le temps, là, je me retire :wink:

Merci pour ta contribution :slightly_smiling:

#11

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.

1 J'aime
#12

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
#13

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, on peut lire :

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 “poor-quality SSD device” mais bon…
Ne serait-il pas mieux de faire un cron hebdomadaire de cette commande ?

#14

@Eric75

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 …

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 “nice -n +15” en me disant " pour laisser le champ libre "

J’ai une entrée crontab :

#15

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.

smartctl -A /dev/sdc

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 “non queued”.

1 J'aime
#16

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.

#17

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 “smartctl” pour ce propos ;


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

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 ?

#18

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

Merci de ton questionnement r2mi.

#19

Merci SylvainMuller, c’est gentil à toi

Nous apprenons ici que le disque SSD Sata 3.0 donne “queued TRIM support allowing TRIM commands to be queued with I/O requests”

Donc pour ces matériels les plus récents ça donne la possibilité, sans équivoque j’imagine, de placer l’option “discard” 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 ;

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-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_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-1.html

Une question reste posée pour les machines équipées de contrôleurs AHCI “anciens” et d’un SSD SATA 3.0 :

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

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 “discard” 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

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

rappel : c’est soit un “fstrim -v /” dans /etc/rc.local (et/ou éventuellement une entrée crontab - comme l’indique intelligemment Eric75) OU BIEN l’option “discard” 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 “discard” 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 “discard” pour le swap ; je l’ai moi-même appliqué.

#20

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 ?