Questions sur l'installation et la configuration de Manjaro Linux.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#1Messageil y a 2 ans

Bonjour à tous.
J’aimerais changer la planification de TRIM pour passer d’une exécution hebdomadaire à une exécution journalière.
Donc, j’ai fait :

sudo systemctl edit fstrim.timer
J’édite le fichier et Ctrl+o pour enregistrer et Ctrl+x pour sortir.
Là, le terminal me dit :

Editing "/etc/systemd/system/fstrim.timer.d/override.conf" canceled: temporary file is empty.
Quelqu’un a-t-il une idée pour résoudre mon problème ?
Merci.
Ignace.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#2Messageil y a 2 ans

bonjour,

je suppose que tu entres du code invalide pour systemd dans nano et donc qu'il refuse :saispas:
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...

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#3Messageil y a 2 ans

Bon, j’ai créé le fichier /etc/systemd/system/fstrim.timer.d/override.conf ou j’ai dedans :

[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true
RandomizedDelaySec=6000

[Install]
WantedBy=timers.target
J’ai fait un :

sudo systemctl daemon-reload
La commande suivante me donne :

$sudo systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/fstrim.timer.d
             └─override.conf
     Active: active (waiting) since Mon 2022-03-28 13:46:35 CEST; 5min ago
      Until: Mon 2022-03-28 13:46:35 CEST; 5min ago
    Trigger: Tue 2022-03-29 00:24:08 CEST; 10h left
   Triggers: ● fstrim.service
       Docs: man:fstrim
             man:fstrim

mars 28 13:46:35 ignace-pc systemd[1]: fstrim.timer: Deactivated successfully.
mars 28 13:46:35 ignace-pc systemd[1]: Stopped Discard unused blocks once a week.
mars 28 13:46:35 ignace-pc systemd[1]: Stopping Discard unused blocks once a week...
mars 28 13:46:35 ignace-pc systemd[1]: Started Discard unused blocks once a week.
13:52:ignace:~$sudo systemctl edit fstrim.timer
13:53:ignace:~$sudo systemctl edit fstrim.timer
13:58:ignace:~$sudo systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/fstrim.timer.d
             └─override.conf
     Active: active (waiting) since Mon 2022-03-28 13:46:35 CEST; 12min ago
      Until: Mon 2022-03-28 13:46:35 CEST; 12min ago
    Trigger: Tue 2022-03-29 00:29:44 CEST; 10h left
   Triggers: ● fstrim.service
       Docs: man:fstrim
             man:fstrim

mars 28 13:46:35 ignace-pc systemd[1]: fstrim.timer: Deactivated successfully.
mars 28 13:46:35 ignace-pc systemd[1]: Stopped Discard unused blocks once a week.
mars 28 13:46:35 ignace-pc systemd[1]: Stopping Discard unused blocks once a week...
mars 28 13:46:35 ignace-pc systemd[1]: Started Discard unused blocks once a week.
Quand je fais la commande suivante, il donne ça :

14:24:ignace:~$systemctl cat fstrim.timer
# /usr/lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=6000

[Install]
WantedBy=timers.target

# /etc/systemd/system/fstrim.timer.d/override.conf
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true
RandomizedDelaySec=6000

[Install]
WantedBy=timers.target
~
~
~
~
~
~
~
Quand je fais la commande suivante, ça me fait :

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

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#4Messageil y a 2 ans

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.
Source : https://www.techtarget.com/searchstorag ... ition/TRIM

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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#5Messageil y a 2 ans

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

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 :gsourire: Et il est si sûr de lui qu'il ne prend même pas la peine de donner un début d'argument. :rigole:

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: :rendre: pour les bêtises

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#6Messageil y a 2 ans

Bon, j’ai corrigé mon override.conf.
Ce monsieur contredit donc les réglages de toutes les distributions... cool, il est plus fort que l'équipe debian, arch ou ubuntu :gsourire: Et il est si sûr de lui qu'il ne prend même pas la peine de donner un début d'argument. :rigole:
(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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#7Messageil y a 2 ans

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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#8Messageil 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
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 :gsourire:

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)

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#9Messageil y a 2 ans

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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#10Messageil y a 1 an

Bonjour à tous.
J’ai reçu la réponse de Samsung :
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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#11Messageil y a 1 an

ignace72 a écrit : il y a 1 an 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 :lol: sinon ta config n'a pas de sens :wink:

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

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é

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#12Messageil y a 1 an

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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#13Messageil y a 1 an

ignace72 a écrit : il y a 1 an 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% ... :saispas: 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 :lol:

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#14Messageil y a 1 an

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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#15Messageil y a 1 an

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

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#16Messageil y a 1 an

:salut:
Suite ... :gsourire:
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 :pleure: ) 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 :gsourire:
"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. :pompom:

le script modifié :

#!/bin/bash

#######################################
# Variables                           #
#######################################

SSD_DEVICE="/dev/sda"

ON_TIME_TAG="Power_On_Hours"
WEAR_COUNT_TAG="Wear_Leveling_Count"
LBAS_WRITTEN_TAG="Total_LBAs_Written"
LBA_SIZE=512 # Value in bytes

BYTES_PER_MB=1048576
BYTES_PER_GB=1073741824
BYTES_PER_TB=1099511627776

#######################################
# Get total data written...           #
#######################################

# Get SMART attributes
SMART_INFO=$(sudo /usr/sbin/smartctl -A "$SSD_DEVICE")

# Extract required attributes
ON_TIME=$(echo "$SMART_INFO" | grep "$ON_TIME_TAG" | awk '{print $10}')
WEAR_COUNT=$(echo "$SMART_INFO" | grep "$WEAR_COUNT_TAG" | awk '{print $4}' | sed 's/^0*//')
LBAS_WRITTEN=$(echo "$SMART_INFO" | grep "$LBAS_WRITTEN_TAG" | awk '{print $10}')

# Convert LBAs -> bytes
BYTES_WRITTEN=$(echo "$LBAS_WRITTEN * $LBA_SIZE" | bc)
MB_WRITTEN=$(echo "scale=3; $BYTES_WRITTEN / $BYTES_PER_MB" | bc)
GB_WRITTEN=$(echo "scale=3; $BYTES_WRITTEN / $BYTES_PER_GB" | bc)
TB_WRITTEN=$(echo "scale=3; $BYTES_WRITTEN / $BYTES_PER_TB" | bc)

created=$(stat / | awk '/Créé/ {print $2}')
datecreate=$(date -d "$created" "+%s")
datenow=$(date "+%s" )
period=$((60*60*24)) # days
datediff=$(( ($datenow - $datecreate)/($period) ))

# Output results...
echo "------------------------------"
echo " SSD Status:   $SSD_DEVICE"
echo "------------------------------"
echo " On time:      $(echo $ON_TIME | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta') hr"
echo " Depuis:       $created (soit $datediff jours)"
echo "------------------------------"
echo " Data written:"
echo "           MB: $(echo $MB_WRITTEN | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "           GB: $(echo $GB_WRITTEN | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "           TB: $(echo $TB_WRITTEN | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "------------------------------"
echo " Mean write rate:"
echo "        MB/hr: $(echo "scale=3; $MB_WRITTEN / $ON_TIME" | bc | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "        Go/jour: $((($BYTES_WRITTEN / $BYTES_PER_GB) / datediff))"
echo "------------------------------"
echo " Drive health: ${WEAR_COUNT} %"
echo "------------------------------"

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#17Messageil y a 1 an

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.
Dernière modification par ignace72il y a 1 an, modifié au total 1 fois.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#18Messageil y a 1 an

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.

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#19Messageil y a 1 an

Salut,
ignace72 a écrit : il y a 1 an 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 

Planification de TRIM, passer d’une exécution hebdomadaire à une exécution journalière

#20Messageil y a 1 an

Smurf a écrit : il y a 1 an 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 :wink:
Moi aussi 6 jours ! normal nous avons le même timer :lol: un ralentissement ? :saispas: pas vu/ressenti
Répondre