Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Alors comment bien faire?
Je suis récemment dans Linux. Alors merci de me donner intégralement toutes les lignes de code qu'il faut faire.
Edit à toto : pour rendre le code sur le forum plus lisible il faut utiliser la balise Autre code (code) et non Citation (quote)
Hors ligne
Hors ligne
Hors ligne
De plus, tous suggèrent d'enlever la fonction d'hibernation.
Sources de cette affirmation et dans quel contexte ? 
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Est-ce correct?
Comment faire pour savoir si tout fonctionne ???
Dernière modification par clodben (23-04-2018 15:32:10)
Hors ligne
sudo chown root:root /swapfile
Est-ce qu'il faudrait que j'ay place tout le chemin :
/dev/mmcblk0p1/swapfile
ou
/media/semaphorus/LexarF32/swapfile
bien entendu vous avez compris que semaphorus c'est le nom du compte et LexarF32 le label de la carte
Merci
Hors ligne
toutes sortes de rumeurs circulent à cet effet, je ne sais plus qui croire
Il ne faut croire aucune rumeur. Une rumeur est fausse. Si elle était vraie, ce serait un fait et non une rumeur.
De plus, tous suggèrent d'enlever la fonction d'hibernation.
Sans swap, l'hibernation n'est pas possible.
Pour enlever le swap, il faut d'abord le désactiver.
Ensuite, éditer le fichier /etc/fstab en tant que root pour "commenter" (insérer un # en début de ligne) la ligne relative au swap.
Maintenant on peut supprimer la partition de swap avec son éditeur de partition favori, en root (fdisk, parted, gparted, gnome-disks...)
Comment transférer ailleurs (ex.: carte SD ou mini-clé usb) les répertoires suivant :HOME, DATA, TMP etc ?
Je ne te dirai pas comment car je pense que c'est une très mauvaise idée à tous les points de vue (performance, fiabilité). Les clés USB et cartes SD sont lentes (particulièrement en écriture) et ne sont pas conçues pour les écritures répétées, contrairement aux SSD.
Quant à ce que propose celp, c'est juste remplacer une partition de swap par un fichier de swap. Aucun intérêt.
donc dans le fichier fstab j'ai écrit :
/dev/mmcblk0p1/swapfile none swap defaults 0 0
Est-ce correct?
Non. /dev/mmcblk0p1 n'est pas un répertoire, c'est un fichier spécial de périphérique qui représente la première partition de la carte SD.
De plus à quoi sert la commande
sudo chown root:root /swapfile
Elle sert à donner la propriété du fichier au super-utilisateur root, ce qui est superflu puisque root est déjà propriétaire du fichier (à moins peut-être d'avoir une configuration de sudo très tordue).
Est-ce qu'il faudrait que j'y place tout le chemin :
/dev/mmcblk0p1/swapfile
ou
/media/semaphorus/LexarF32/swapfile
Traitons la question de façon théorique puisque tu ne vas pas mettre un swap sur une carte SD.
Il faudrait mettre le chemin par lequel le fichier est accessible. Mais il ne faut pas mettre ce chemin-ci. Il correspond à un montage effectué depuis la session d'un utilisateur normal (semaphorus). Ce montage n'existe pas encore au démarrage lorsque le système va chercher à activer le swap. Il faudrait donc insérer dans /etc/fstab une ligne pour monter le volume contenant le fichier de swap avant la ligne du swap.
Il vaut mieux montrer que raconter.
Hors ligne
Au taf, on a tous des SSD depuis 2-3 ans, avec windows et sans configuration particulière donc le cache sur SSD
Quel cache ?
j'ai gardé l'utilisation du swap en la faisant pointer vers une partition du vieux disque mécanique
La seule raison valable de faire cela, c'est s'il n'y a pas assez de place sur le SSD. Le swap fait partie des meilleurs candidats au placement sur un SSD.
régler swapiness pour ne pas l'utiliser avant d'avoir rempli 90% de la RAM.
Tu fais erreur. La valeur de swappiness n'a rien à voir avec le taux d'occupation de la mémoire. Elle définit seulement la tendance soit à swapper (vers 100), soit à vider du cache (vers 0) lorsqu'il ne reste plus assez de mémoire libre.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
TRIM à la volée
La fonction TRIM est disponible pour ext4 depuis la version 2.6.33 du noyau Linux (à noter, si vous utilisez Debian 6 Squeeze, que la version 2.6.32 du noyau présente dans les dépôts officiels Backports gère le TRIM – les petits gars de Debian ayant bien bossé comme d'habitude ;-)
Pourtant elle n'est pas active par défaut... Pour y remédier, vous devrez ajouter discard sur la ligne de votre partition dans le fichier /etc/fstab.
Remplacer :
errors=remount-ro
par :
errors=remount-ro,discard
Ce n'est pas mentionné dans la documentation ( qui explique aussi comment transférer son système de l'ancien au nouveau disque ) : https://wiki.debian.org/SSD%20Installat … figuration
Cette page de documentation mériterai d'être traduite !
De plus j'ai ajusté mon fstab de la façon suivante:
Est-ce les bonnes opérations? Sinon je puis vous dire que j'ai jamais vu un OS se charger si vite Boot en moins de 5 secondes...
Merci
Dernière modification par clodben (24-04-2018 14:46:54)
Hors ligne
Dans le lien de Michael62140, il parle d'ajouter discard à la ligne du ssd dans le /etc/fstab
L'option de montage "discard" n'est pas le seul moyen d'utiliser le TRIM des SSD. On peut aussi lancer un TRIM avec la commande "fstrim", généralement dans une tâche périodique. Apparemment, le fstrim périodique est préféré car marquer les blocs libérés immédiatement comme le fait l'option discard n'est pas indispensable et le TRIM peut déclencher une opération de "ramasse-miettes" (garbage collector) susceptible de dégrader l'accès au SSD dans certains cas, ce qui n'est pas souhaitable quand la machine effectue des entrées-sorties intensives sur le SSD. Donc il peut être préférable de programmer le TRIM à un moment où on sait que la machine est peu chargée.
Dernière modification par raleur (24-04-2018 14:54:34)
Il vaut mieux montrer que raconter.
Hors ligne
Pas besoin de SWAP alors, j'ai fait :
Quelque chose d'incohérent. Si tu n'as pas besoin de swap, pourquoi avoir créé un fichier de swap sur la racine ?
Pourquoi l'avoir activé (swapon) puis désactivé (swapoff) ?
Il vaut mieux montrer que raconter.
Hors ligne
Exécuter fstrim fréquemment, ou même utiliser mount -o discard, pourrait affecter négativement la durée de vie des périphériques SSD de mauvaise qualité. Pour la plupart des systèmes de bureau ou des serveurs, la fréquence d’abandon suffisante est une fois par semaine. Remarquez que tous les périphériques ne permettent pas de mettre en attente les abandons, donc chaque commande d’abandon pénalise les performances de tout ce qui pourrait être en train d’essayer d’utiliser le disque en même temps.
Exécuter fstrim fréquemment, ou même utiliser mount -o discard, pourrait affecter négativement la durée de vie des périphériques SSD de mauvaise qualité
Des SSD de très mauvaise qualité alors, à fuir. La seule raison que je vois pour laquelle l'usage répété du TRIM pourrait écourter la durée de vie d'un SSD est que cela déclencherait un ramasse-miette (qui provoque des écritures) à chaque fois. L'exécution du TRIM n'est pas censée déclencher d'action immédiate autre que le simple marquage des secteurs "abandonnés" (et non leur effacement), marquage qui pourra ensuite être exploité par le ramasse-miettes qui sera déclenché à un moment opportun (et quand le SSO est peu sollicité).
tous les périphériques ne permettent pas de mettre en attente les abandons, donc chaque commande d’abandon pénalise les performances de tout ce qui pourrait être en train d’essayer d’utiliser le disque en même temps.
Je suppose que cette phrase fait référence aux deux types de commande TRIM ATA : "non-queued" (la plus ancienne) et "queued" (plus récente). La commande "non-queued" impose de vider toute la file d'attente des commandes de lecture/écriture en cours et empêche d'en envoyer d'autres pendant son exécution. La version "queued" n'a pas cet inconvénient mais elle n'est pas supportée par les SSD les plus anciens et elle peut provoquer des corruptions de données sur certains SSD dont le firmware est buggé. Le noyau contient une liste noire de modèles de SSD connus pour avoir ce type de bug et refuse d'utiliser le TRIM "queued" avec l'un d'eux, se limitant alors au TRIM "non-queued" plus pénalisant pour les performances.
A noter que les SSD NVMe n'utilisent plus le protocole ATA donc leur gestion du TRIM est probablement différente.
Dernière modification par raleur (24-04-2018 16:42:43)
Il vaut mieux montrer que raconter.
Hors ligne