Trouver une erreur journaux système

[Robinwood]

Dernier message de la page précédente :

Avec google, j'ai plusieurs fois trouvé sur le samsung evo 850 (mon ssd):

850 EVOne supporte pas TRIM en file d'attente.
les commandes TRIM ne doivent pas être mis en attente par le lecteur, mais
exécutée immédiatement (après avoir effacé les commandes existantes dans la file d'attente, je
deviner). Pour une utilisation de bureau, cela signifie qu'un fstrim hebdomadaires cronjob vous pouvez
ont peut bloquer le système pendant une seconde.

Code : Tout sélectionner

libata.force = noncq 

comme paramètre du noyau, semble être la solution, à suivre.
Dois-je désactiver fstrim:cron.weekly?

[Robinwood]

Bonjour,
le portable vient de refigé, je remet grub comme avant, vu que cela ne change rien, je laisse fstrim dans cron.weekly.
Heure approximative 08 h 01.
Une copie de journaux système:


http://www.howtoeverything.net/linux/ha ... sd-upgrade
solution deux agrandir le swap, je le passe à 16 GB pour 8GB ram et un swappiness à 5, à suivre.

[Robinwood]

Je teste cette solution de douibler le swap, à voir.
Voila mon nouveau système de partition, avec un swap de 17 GB.

Je laisse un swappiness à 5

[mpat]

Je pense que tu chipote trop avec cette commande trim.

La commande TRIM à la volée est activée par défaut à partir d'Ubuntu 14.04 LTS sur les partitions ext4 et BTRFS, aucune modification à faire à partir de cette version.

Notez encore une fois que depuis Ubuntu 14.04 LTS, la commande TRIM est activée par défaut. L'usage de la méthode décrite ici n'est pas recommandée. (la méthode décrite c'est celle que tu emplois.)

Vous pouvez vérifier la prise en charge de la commande TRIM par votre SSD par la commande suivante où vous remplacez /dev/sda par l'identifiant de votre disque :

sudo hdparm -I /dev/sda | grep TRIM

[Robinwood]

J'ai remis fstrim comme à l'installation, il est dans cron.weekly par défaut.

Code : Tout sélectionner

sudo hdparm -I /dev/sda | grep TRIM
[sudo] password for robin: 
	   *	Data Set Management TRIM supported (limit 8 blocks)

Penses-tu que doubler le swap peut jouer?

[mpat]

Si tu fais de l'hibernation 1.5 x ta ram. Si pas d'hibernation non, je ne fais pas d'hibernation, j'ai un swap de 3go commun à Maté et Cinnamon, sur mon dd mécanique swappiness réglé à 5. et je n'ai jamais de blocage ou freeze.

j'ai aussi un Samsung 256GB 850 PRO Series SATA 2.5" SSD

Pour moi tu ne dois pas mettre de commande trim, étant donné qu'elle est activée par défaut, mais tu fais comme tu veux.

[Robinwood]

Ok, je supprime fstrim,
je le fais de toute façon manuellement de temps en temps sans erreurs annoncées.
Merci Mpat, tu "m'pat" .
Je laisse la swappiness à 5.
Par sécurité le swap X1.5.
Encore un énorme merci, suite au prochain gèle.

[Robinwood]

En modifiant le swap en live, j'ai vérifier, fstrim est bien dans cron.weekly.
Je l'ai donc remis à sa place.

[zeb]

Robinwood, mpat a raison, c'est pour ton ssd que tu as mis ça ?
Moi mon ssd, je n'ai rien fait, j'ai installé mint comme sur un dd classique, tous ces trucs c’était pour le début des ssd, mais aujourd'hui ce n'est plus d'actualité

Au pire sur 5 ans de vie tu vas gagner 1 mois, pas la peine de se prendre la tête avec des tas de commandes, certains mettent même le home sur ssd et ça roule depuis quelques années

[mpat]

moi j'ai / et /home sur mon ssd juste le swap sur le mécanique. en plus Gsmartcontrol est bien plus complet comme outils pour les ssd.

en plus depuis la version 14.04 le trim est automatique donc lancer une 2ème fois le processus alors qu'il est actif peux aboutir à un plantage.

[Robinwood]

Quel idiot je fais!!!
Avec ces histoires de piratage, j'ai pensé à vérifier les md5 de l'iso téléchargé il y a un moment, résultat mauvais
J'ai retéléchargé sur le site officiel, vérifié md5, je suis entrain de mettre à jour.
Je ne touche à rien, à part le swappiness que je passe à 5.
Merci de votre soutien .
A suivre...si c'était cela le problème.