je suppose que tu entres du code invalide pour systemd dans nano et donc qu'il refuse
Sinon, il est toujours possible de créer ce fichier (donné en erreur) manuellement
ps: pourquoi ce changement ? tu as une source ? je ne suis pas spécialiste mais ftrim attaque dur le ssd donc il faut au contraire l'espacer le plus possible pour le bien-être de notre disque...
$sudo systemctl list-timers --all
[sudo] Mot de passe de ignace :
NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2022-03-28 23:05:56 CEST 8h left Sun 2022-03-27 23:05:56 CEST 15h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Tue 2022-03-29 00:00:00 CEST 9h left Mon 2022-03-28 00:00:36 CEST 14h ago logrotate.timer logrotate.service
Tue 2022-03-29 00:00:00 CEST 9h left Mon 2022-03-28 00:00:36 CEST 14h ago pkgfile-update.timer pkgfile-update.service
Tue 2022-03-29 00:00:00 CEST 9h left Mon 2022-03-28 00:00:36 CEST 14h ago shadow.timer shadow.service
Tue 2022-03-29 00:24:19 CEST 10h left Mon 2022-03-28 01:29:24 CEST 12h ago updatedb.timer updatedb.service
Tue 2022-03-29 00:29:44 CEST 10h left Mon 2022-03-28 12:50:57 CEST 1h 21min ago fstrim.timer fstrim.service
Tue 2022-03-29 11:26:34 CEST 21h left Mon 2022-03-28 01:28:39 CEST 12h ago man-db.timer man-db.service
Thu 2022-03-31 16:01:16 CEST 3 days left Thu 2022-03-24 10:14:34 CET 4 days ago pamac-mirrorlist.timer pamac-mirrorlist.service
Sat 2022-04-02 15:00:00 CEST 5 days left Sat 2022-03-05 15:00:00 CET 3 weeks 1 day ago pamac-cleancache.timer pamac-cleancache.service
Bonjour, papajoke.
J’ai trouvé la définition du travail TRIM automatique sur quotidien ici : https://easylinuxtipsproject.blogspot.c ... d.html#ID6
Je veux bien croire que TRIM attaque dur le SSD, mais quelle est la différence entre 10 actions sur le SSD tous les jours et 70 actions sur le SSD toutes les semaines ?
TRIM ne fera pas plus d’actions sur le disque SSD s’il est réglé pour le faire tous les jours ou toutes les semaines, non ?
Merci.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
Je pense aussi à une chose, Manjaro a souvent des mises à jour en bloc. Des tas de paquets sont mis à jour au même moment. Si TRIM se lance une fois par semaine le dimanche (par exemple) et que la grosse mise à jour arrive le lundi, le disque SSD passera une semaine à fonctionner avec des blocs désorganisés et écrira les nouvelles données de façon non homogène sur la totalité du disque. Pourtant, pour durer longtemps, un SSD DOIT écrire (supprimer ou ajouter des données) de façon homogène sur tous les blocs du SSD.
Les SSD basés sur la mémoire flash NAND lisent et écrivent des données dans des unités appelées pages , et dans un SSD typique, 128 pages constituent un seul bloc . Mais, avant que des données puissent être écrites ou programmées sur le SSD, un bloc entier de données qui n'est plus nécessaire doit être effacé. Une opération d'entretien interne SSD connue sous le nom de récupération de place aide à rationaliser le processus.
Le nettoyage de la mémoire gère et maintient l'espace de stockage disponible, en gérant la disparité entre la taille de l'unité d'effacement (bloc) et la taille de l'unité de lecture/écriture (page). Lorsqu'un bloc précédemment écrit est ciblé pour la récupération de place, les pages de données valides sont rassemblées et déplacées vers un autre bloc sur le SSD afin que le bloc contenant les anciennes pages de données non valides puisse être effacé. La récupération de place peut attendre des accalmies dans l'activité du lecteur pour lancer le processus, laissant parfois des pages obsolètes dans le SSD.
TRIM est complémentaire à la récupération de place. La commande TRIM permet au système d'exploitation (OS) de notifier de manière préventive au SSD quelles pages de données d'un bloc particulier peuvent être effacées, permettant au contrôleur du SSD de gérer plus efficacement l'espace de stockage disponible pour les données. TRIM élimine toute copie inutile des pages de données rejetées ou invalides pendant le processus de récupération de place pour gagner du temps et améliorer les performances du SSD.
Donc c’est pour ça que je pense que faire fonctionner TRIM une fois par jour n’est pas une mauvaise idée.
Enfin, c’est comme ça que je vois les choses.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
1) Tu ne suis même pas ce bog ?
il écrit de mettre dans ce override.conf uniquement ces 3 lignes
[Timer]
OnCalendar=
OnCalendar=daily
Et toi tu recopies toute la config ! il ne faut mettre que ce que l'on désire surcharger : surcharger des valeurs par les mêmes valeurs n'a pas de sens
2) daily
Ici, c'est une remarque d'uniquement un blogueur sans aucun argument !
Mais dans de nombreux (la plupart ?) cas, une fois par semaine n'est pas assez fréquent : attendre une semaine entière avant que l'espace disque récupérable ne redevienne utilisable, c'est tout simplement trop long.
Ce monsieur contredit donc les réglages de toutes les distributions... cool, il est plus fort que l'équipe debian, arch ou ubuntu Et il est si sûr de lui qu'il ne prend même pas la peine de donner un début d'argument.
En fait, oui, dans un cas particulier, cela est un plus : si tu manques de place sur ton ssd !!!
- occupation à plus de 80% ? (chiffre tiré de ma boule de cristal : suis pas expert)
- Si tu supprimes de gros fichiers tous les jours (ex: 10 fichiers iso/vidéo par jour...)
ignace72 a écrit : ↑il y a 2 ans
des mises à jour en bloc.
fstrim c'est pour les supressions, lors d'une maj, les fichiers existent déjà donc linux écrit dans les fichiers existants. Il va peut-être supprimer 1..3 fichiers au total : fichiers qui n'existent plus dans les paquets
EDIT: pour les bêtises
Ce monsieur contredit donc les réglages de toutes les distributions... cool, il est plus fort que l'équipe debian, arch ou ubuntu Et il est si sûr de lui qu'il ne prend même pas la peine de donner un début d'argument.
(sous Windows, TRIM est aussi réglé par défaut pour un fonctionnement hebdomadaire)
Ben, ce ne sera pas le premier réglage par défaut que l’on change.
Une fois une distribution installée, on passe des plombes à changer les réglages par défaut de la distribution.
On modifie par exemple : fstab qui n’est jamais configuré comme on veut.
On installe des programmes qui nous paraisses indispensables qui ne sont pas installés par défaut, exemple : ACPID.
Un réglage par défaut n’est pas gravé dans le marbre, il n’est pas forcément voué à rester en l’état.
Si j’avais laissé mon système par défaut, jamais je n’aurais pu connaître l’état de mon onduleur et laisser le système s’arrêter automatiquement en cas de coupure de courant prolongée.
Pour les disques SSD qui sont des disques de stockage rapides, l’ordonnanceur d'entrée/sortie par défaut (mq-deadline) n’est pas vraiment adapté, le disque SSD fonctionnera, mais pas de façon optimale, il vaut mieux lui préférer kyber.
Ça peut aussi être plus futile comme modifier son .bashrc, mais c’est aussi sortir des réglages par défaut.
Garder les réglages par défaut, ça permet d’avoir un système fonctionnel quelque soit son utilisation ou son matériel.
C’est à ça que servent les réglages par défaut, mais le système ne sera jamais optimisé. En plus, certains réglages par défaut ne sont pas adéquats pour certains matériels (composants de l’ordinateur ou matériels externes).
C’est comme les programmes installés par défaut, ils permettent d’avoir un système fonctionnel, mais il ne sera jamais optimisé en, plus, en gardant uniquement les programmes par défaut, on se prive aussi de certains matériels qui ont besoin de pilotes non fournit par défaut.
Sur le wiki d’ArchLinux, il y a même une page dédiée pour améliorer les performances donc sortir des réglages par défaut : https://wiki.archlinux.org/title/Improv ... %C3%A7ais).
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
papajoke a écrit : ↑il y a 2 ansfstrim c'est pour les supressions, lors d'une maj, les fichiers existent déjà donc linux écrit dans les fichiers existants. Il va peut-être supprimer 1..3 fichiers au total : fichiers qui n'existent plus dans les paquets
Lors d’une mise à jour, des fichiers sont modifiés, donc pour chaque fichier modifié, le SSD doit supprimer la partie modifiée et écrire la nouvelle partie. Si le SSD peut écrire la page modifiée, il ne peut pas supprimer la page modifiée, il est obligé de supprimer le bloc entier donc des parties du fichier qui n’ont pas été modifiées donc finalement, il sera obligé d’écrire le bloc entier. Et non s’il y a une mise à jour d’un fichier, donc un nombre de pages et de blocs, le SSD ne peut pas écrire dedans. Il écrit les nouvelles pages et blocs ailleurs et supprime les anciens.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
Je ne t'ai pas dit de ne pas faire d'optimisations !
Il faut juste être très prudent et surtout vérifier 36 sources : 1 unique blog, pour moi, c'est poubelle direct
je ne suis qu'un utilisateur (avancé) donc je ne remets pas en cause ce que va écrire un ingénieur système ou les codeurs linux. Et si je ne comprends pas bien ce que je fais, je préfère ne pas le faire ("ne pas péter plus haut que...") En 9 ans de manjaro, je ne me suis jamais retrouvé avec un système non fonctionnel au boot, donc je pense que ma prudence fonctionne pas mal...
ps: je parle en général, ici, cette modification n'est pas dangereuse
Plus on personnalise sa config système, et plus on a un risque à l'update. Reste juste à savoir si l'optimisation est nécessaire pour nous et si on a un bon niveau pour gérer notre custom config. Chacun a ces attentes et son curseur.
Pas compris ton argument pacman "block modifiés", pas grave.
Il suffit de faite le test :
sudo fstrim -A --verbose
# mise à jour pamac/pacman
sudo fstrim -A --verbose
ps: par contre, paccache c'est de la suppression (parfois importante)
-----------
Note: A chaque "optimisation", je commente dans le fichier !!!
# fait ceci
# pourquoi je le fais
# url source
puisque je ne suis qu'une personne normale, cela me permet de gérer mes différences un ou deux ans après (maj qui passe mal ou optimisation non valide maintenant)
papajoke a écrit : ↑il y a 2 ans
Je ne t'ai pas dit de ne pas faire d'optimisations !
Il faut juste être très prudent et surtout vérifier 36 sources : 1 unique blog, pour moi, c'est poubelle direct
D’après, les différentes sources que j’ai pu lire, il n’y a pas d’effet néfaste à faire un fstrim journalier plutôt qu’hebdomadaire.
Pour être sûr, j’ai écrit à Samsung pour leur poser la question (car c’est un Samsung 860 PRO SATA 2.5" SSD 512GB que j’ai), suivant leur réponse, j’appliquerais la journalisation qu’il me recommande.
papajoke a écrit : ↑il y a 2 ansPas compris ton argument pacman "block modifiés", pas grave.
Il suffit simplement de faite le test :
sudo fstrim -n -A --verbose # ne fait rien !!! Affiche uniquement l'espace qui peut-être libéré
# mise à jour pamac/pacman
sudo fstrim -n -A --verbose # pour comparer
ps: par contre, oui, paccache c'est de la suppression (parfois importante)
Oui, c’est un truc à essayer.
Pour ce qui est de paccache, j’ai déjà activé paccache.timer. Par contre cela ne changera rien pour moi sur le SSD, car /var est sur un HDD (/var/tmp et /tmp sont monté dans la RAM avec tmpfs).
papajoke a écrit : ↑il y a 2 ansNote: A chaque "optimisation", je commente dans le fichier !!!
# fait ceci
# pourquoi je le fais
# url source
puisque je ne suis qu'une personne normale, cela me permet de gérer mes différences un ou deux ans après (maj qui passe mal ou optimisation non valide maintenant)
Je ne commente pas systématiquement mes modifications, car c’est souvent les mêmes modifications que je fais donc je commence à les connaître par cœur, mais je garde toujours une copie des fichiers originaux, genre :
fichier.conf.save
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
Nous vous remercions d'avoir contacté le support mémoire de Samsung.
Nous vous informons que le TRIM est une fonction par laquelle le système d'exploitation peut notifier le SSD lorsque les données sont marquées pour effacement ou ne sont plus valides. TRIM contribue à rendre la récupération de place plus efficace en préparant des données non valides pour la suppression. Lorsque le système d'exploitation "supprime" des données, les données ne vont nulle part. L'espace dans lequel il réside est simplement marqué comme "espace libre" qui peut être utilisé plus tard. Par défaut, le système d'exploitation ne laisse pas le SSD savoir quelles données sont maintenant libres.
TRIM permet au système d'exploitation d'informer le SSD des données qui ne sont plus valides, ce qui permet au SSD d'ignorer les données non valides lors de l'exécution de la récupération de place.
l n'y a pas de règle précise à ce sujet. Nos SSD le supportent.
Il n’y aurait donc pas de problème à l’utilisation de fstrim une fois par jour.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
ignace72 a écrit : ↑il y a 2 ans
et une partition /var (34,25 Gio au total).
Donc pour celui-là, un SSD ce ne serait pas raisonnable, car le système écrit constamment dans /var et en plus avec SWAP…
Et si c'est le /home à changer, je ne vois pas non plus un SSD, il est conseillé partout de ne pas mettre un /home sur un SSD, oui bon je sais que ce n’est pas parce que c'est conseillé partout que c'est forcément à ne pas faire.
Je te réponds ici car ce sujet me parait plus adéquat (bien que...)
Nous n'avons pas du tout la même vision !
Si j'achète un ssd c'est uniquement pour la vitesse ! Donc, pour moi, aucun intérêt de ralentir mon système délibérément (en plaçant des composants sur disque dur)
Donc chez moi, même mon home est sur ssd, à part le swap, seuls quelques répertoires home/{musique, téléchargement, vidéo, ...} sont sur disque dur : Avoir les .dot sur disque dur va forcément ralentir le chargement du bureau et ce n'est clairement pas ce que je recherche...
Perso, j'ai fait le chemin inverse de toi: en fonction du TBW j'ai uniquement évalué ce que je pouvais faire ou pas faire (avis des bloggeurs et forumeurs, non merci):
ignace72 a écrit : ↑il y a 2 ans
c’est un Samsung 860 PRO SATA 2.5" SSD 512GB que j’ai
Donc, ton constructeur te garantit un TBW de 600 pour ton modèle
J'ai écrit un petit script, mais avec une simple calculatrice il est facile de faire la même chose, résultat avec ta valeur (après 600To, ton ssd peut mourir) :
Nombre de Go écrits par jour ?
Désire le garder x années ? (20)
Année de: 360 jours
TDW: 600 (nombre total d'octets écrits en téraoctets - 1 To = 1000 Go)
Durée du ssd espérée: 20 ans
Ne pas consommer plus de 83 Go par jour
Comme tu peux le voir, si tu écris 80Go/jour, ton constructeur "garantit" une durée de 20 ans
Avec ta config "serrée", tu es à combien ? 2Go/jour grand grand max ? j'espère que tu as une espérance de vie de 800 ans sinon ta config n'a pas de sens
Dans /var/, nous écrivons peu de chose (logs et maj), ce répertoire est très sollicité surtout pour les serveurs de bases de données et nos "petites" mises à jour chaque quinzaine ne va pas peser lourd sur nos 80Go/jour
Dans notre home (dot files exclusivement), sans doute que la grande charge est le cache navigateur web et cache miniatures de gestionnaire de fichier. A nous de voir si nous avons des dizaines de Go par jour (peut-probable).
En résumé : Tu vas déporter des répertoires uniquement si ton transfert/jour garanti par le constructeur est trop faible pour ta propre utilisation. (Et je n'espère pas utiliser ce ssd dans 50 ans )
Code de mon script de calcul
#!/usr/bin/python
# usage: python twb.py
# https://wintelguy.com/dwpd-tbw-gbday-calc.pl : calculateur en ligne pour vérif chiffres : ok même résultats
def query(prompt, default):
ask = input(f"{prompt} ")
try:
return int(ask)
except ValueError:
return default
# nombre de jours dans l'année ou nous utilisons notre machine
annee = query("Nombre de jours dans une année ou nous utilisons notre pc ? (360)", 360)
tbw = query("TBW du ssd ? (150)", 150)
tbw_go = tbw * 1000
jour = query("Nombre de Go écrits par jour ?", 0)
if not jour:
an = query("Désire le garder x années ? (20)", 20)
print("")
print(f"Année de: {annee} jours")
print(f"TDW: {tbw} (nombre total d'octets écrits en téraoctets - 1 To = 1000 Go)")
if jour:
print(f"Comsommation journalière: {jour} Go")
print("")
print(f"Durée du ssd peut-être de {(tbw_go / jour) / annee:.0f} ans", end="\n")
exit(0)
if an:
print(f"Durée du ssd espérée: {an} ans")
print("")
print(f"Ne pas consommer plus de {tbw_go / (an * annee):.0f} Go par jour", end="\n")
Il permet 2 calculs :
- soit on entre le nombre d'années désirées (retourne écritures max par jour)
- soit on entre le nombre d'écritures que nous faisons par jour (retourne durée de vie du ssd)
ps: TDW est une garantie constructeur donc, bien en dessous de la réalité
Bonsoir, papajoke.
Ha, oui, quand même. Donc l'histoire comme quoi un SSD à une durée de vie très courte par rapport à un HDD est devenu un mythe, car d'après mes recherches, un HDD a une durée de vie moyenne de 10 ans ou a été changé avant ses 10 ans donc si tu me dis que mon SSD aura une durée de vie de 20 ans à raison de 83 Go (77,2998 Gio) par jour ce qui est bien supérieur que ce que je consomme (environ 1 Gio après une mise à jour d'un programme comme Firefox) tout en sachant que /var est sur une partition séparée et que /tmp et /var/tmp sont monté en RAM, là il y a eu une grosse mise à jour et fstrim me dit qu'il y a eu 21,2 Gio de réduits.
Si je me base sur ton calcul converti en Gio de 77,2998 Gio d'écriture par jour, je ne consommerai jamais ça même avec le /home sur le SSD. Si j'ai bien compris, les fichiers dot sont juste des fichiers de configuration donc ça ne fait pas 77 Gio d'écriture par jour.
Donc, si je remets /var (32,72 Gio utilisés) dans la racine (31,50 Gio utilisés) et que je mets mes images et photo RAW (244 Gio) et vidéos (2,79 Tio) sur un HDD, ça me fait un /home qui est utilisé à 102,4 Gio. Ça me fait des partitions racine et /home qui doivent contenir 166,64 Gio. Si je ne compte pas l'espace non alloué du début et de la fin du SSD (6,06 Mio) et la partition /boot/efi (300 Mio), ça me fait 476,64 Gio pour la racine et le /home.
Donc, si je fais une racine de 150 Gio et un /home de 326,64 Gio, c'est bon ?
Mon raisonnement et mes calculs sont-ils bons ? Puis-je faire comme ça ?
J'attends un retour de toi papajoke ou d'autres pour faire quoique ce soit.
Merci.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
ignace72 a écrit : ↑il y a 2 ans
si tu me dis que mon SSD aura une durée de vie de 20 ans
Attention, le seul défaut par rapport à un disque est la limite d'écritures TBW. Je n'ai donné que cela. Dans la durée réelle de vie du ssd, il peut avoir d'autres facteurs mais ici, je n'ai aucune compétence pour t'en parler (usure composants élec par la chaleur ? ... réaction chimique après 10 ans ??)
Si je ne compte pas l'espace non alloué du début et de la fin du SSD (6,06 Mio)
Renseigne-toi sur l'over-provisioning(OP)(Surprovisionnement en fr), excellent pour nos ssd, généralement entre 10 et 25% (me semble que les ssd de ta marque sont pré-réglés avec 7% ... l'utilitaire de ta marque est uniquement sous windows). Donc ne pas partitionner tout son ssd pour l "OP" est une pratique très courante et apporte deux vrais plus.
Pour les tailles des partitions, tu n'es pas un débutant, c'est selon tes besoins/expériences et je n'ai aucune formule magique
Bonsoir, papajoke.
Merci pour ta réponse.
Je me doute que se baser juste sur le TBW, c'est du théorique, qu'il y a énormément de facteurs qui rentrent en compte.
Si je me basais juste sur le MTBF, ça me donnerait 114 ans entre les défaillances du disque.
C'est sûr que ça ne veut rien dire.
Pour le TBW :
le magazine allemand « IT and Computer » a fait des tests pour déterminer la valeur réelle du TBW. Pour ce test, les experts ont acheté deux SSD parmi les 12 « best-sellers » de 2016 et les ont testés pendant un an (jusqu'en juin 2017). Les SSD qui ont été testés étaient : OCZ TR150, Crucial BX 200, Samsung 750 Evo, Samsung 850 Pro, SanDisk Extrême Pro et SanDisk Ultra II.
Les experts ont utilisé des utilitaires permettant d’analyser les performances des SSD et remplir les disques avec des écritures répétitives.
Le résultat des tests effectués était étonnant : la quantité totale de données écrites sur les disques dépassait la capacité maximale donnée par le constructeur. Même les disques les moins chers ont supporté plus de données écrites que la capacité donnée par le constructeur. Les disques Crucial BX200 ont été en mesure d'écrire 187 TB et 280 TB - 2,5 fois le chiffre promit!
L'un des disques Samsung, SSD 850 PRO, atteint un chiffre de 9,1 pétaoctets de données écrites ! C'est 60 fois le chiffre TBW promis par Samsung dans ses fiches techniques. Le disque Samsung le moins cher, le Samsung SSD 750 Evo, était capable d'écrire 1,2 pétaoctet de données. Cela équivaut en théorie à plus de 80 ans d'écriture continue. Pour les modèles pro, les tests ont démontré pourquoi leur prix est plus élevé. Aucun d'eux n'a écrit moins de 2,2 pétaoctets de données.
Les résultats obtenus par ce test prouvent que la durée de vie des SSD est plus élevée par rapport à celle donnée par les constructeurs.
Je me suis renseigné sur le surprovisionnement et d'après ce que j'ai pu lire, tous préconisent de laisser de la place libre sans partition sur les disques. Par contre quid de la taille à laisser vide…
Bon, si je fais une racine à 100 Gio et un /home à 300 Gio ce qui me laisse 197,60 Gio de libre sur le /home donc ça laisse le temps de voir venir, ce qui reste, ça fait environ 20 % pour le surprovisionnement donc je ne dois pas être mal.
Bon, je télécharge la dernière image ISO.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
À chaque lancement de TRIM, ça dit que ça récupère 299,11 Gio sur ma partition /boot/efi/.
En fait, ça correspond exactement à l'espace libre de ma partition /boot/efi/.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
Suite ...
Il peut être bon de vérifier si on n'abuse pas d'écritures sur notre ssd
J'ai trouvé un petit script que j'ai transformé pour me donner une valeur Go/jour
smartctl donne un chiffre sur l'écriture (pas forcément exact ) mais c'est bien la seule chose qui est mesurable
ma technique (en plus):
- Je récupère la date de création de notre système pour en déduire le nombre de jours entre aujourd'hui et la création
- Ce qui me permet d'afficher un Go/jour pour le comparer à notre quota journalier maxi calculé depuis TBW:
Mon résultat:
------------------------------
SSD Status: /dev/sdb
------------------------------
On time: 9,554 hr
Depuis: 2019-01-29 (soit 1173 jours)
------------------------------
Data written:
GB: 6,288.319
TB: 6.140
------------------------------
Mean write rate:
MB/hr: 673.983
Go/jour: 5
J'ai donc avec ma config "beaucoup sur ssd"(même le cache du navigateur web est sur ssd) écrit 6To en près de 3 ans. Me reste donc environ plus que mon TBW - 6 : soit beaucoup beaucoup de marge
"Go/jour: 5", Attention !!! Nous avons un calcul avec aussi les jours où nous n'utilisons pas notre PC, donc le 673 Mo/heure peut être plus parlant ? Si je fais des sessions de 8 heures par jour, je suis à (673*5) 5Go/jour
En résumé, en calculant le nombre d'heures d'utilisation de mon ssd, ou me basant sur la création de mon système, j'arrive grosso modo aux mêmes chiffres qui me laissent énormément de marge.
Bonjour, papajoke.
Merci pour ton script.
Tu peux en faire profiter les autres en le posant dans le sous-menu du forum « Trucs & Astuces », enfin tu fais ce que tu veux.
Mon SSD fait mieux :
17:49:ignace:~$sh test-disque-ssd.sh
[sudo] Mot de passe de ignace :
Désolé, essayez de nouveau.
[sudo] Mot de passe de ignace :
------------------------------
SSD Status: /dev/sda
------------------------------
On time: 1,848 hr
Depuis: 2022-02-10 (soit 65 jours)
------------------------------
Data written:
MB: 289,244.851
GB: 282.465
TB: .275
------------------------------
Mean write rate:
MB/hr: 156.517
Go/jour: 4
------------------------------
Drive health: 100 %
------------------------------
17:49:ignace:~
Je suis à Go/jour: 4
Et 156 Mio/heure en sachant que mon ordinateur fait des sessions de 24 heures par jour.
Je verrais bien ce que ton script me dit sur l'utilisation de mon SSD dans le futur.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
Dernière modification par ignace72il y a 2 ans, modifié au total 1 fois.
J'ai fait les changements.
Résultat de l'opération :
19:52:ignace:~$sudo fstrim -A --verbose
[sudo] Mot de passe de ignace :
/home : 190 GiB (203999338496 octets) réduits sur /dev/sda3
/ : 58,1 GiB (62397083648 octets) réduits sur /dev/sda2
/boot/efi : 299,1 MiB (313634816 octets) réduits sur /dev/sda1
Le gain de vitesse est sensible au démarrage de la session XFce.
Ignace.
PC de bureau.
AMD Ryzen 3 1200 Quad-Core, 32 Go de Ram DDR4, Radeon HD 7750 fanless.
Manjaro stable, KDE.
ignace72 a écrit : ↑il y a 2 ans
Le gain de vitesse est sensible au démarrage de la session XFce.
Je ne vois pas trop le rapport entre le trim et la vitesse de boot, un trim fréquent est intéressant si on a un disque plein ou presque, ou si on écrit/efface de grosses quantités de données régulièrement, l'amélioration se fait au niveau de l'écriture, pas de la lecture.
6 jours et demi depuis mon dernier trim, mon boot de ce matin (l'exécution du bios est de ~6s) :
systemd-analyze
Startup finished in 920ms (kernel) + 684ms (initrd) + 2.970s (userspace) = 4.576s
graphical.target reached after 2.970s in userspace
Smurf a écrit : ↑il y a 2 ans
pas trop le rapport entre le trim et la vitesse de boot
En effet, le sujet a débordé, ici, il utilise la commande trim uniquement pour montrer que maintenant le home est sur ssd.
C'est ce déplacement qui donne un petit coup de boost
Moi aussi 6 jours ! normal nous avons le même timer un ralentissement ? pas vu/ressenti