Barre rouge disque dur

Dark-Angel66

Grand Maître
Salut à tous :)

Petite question très rapide : mon disque C SSD M.2 est rouge très vite, exemple : il me reste 80 Go de libre (c'est pas un disque de stockage) donc je suis large ! Pourquoi c'est déjà rouge ? C'est juste esthétique, j'aimerai dire à Windows de me l'afficher en rouge quand c'est VRAIMENT un problème parce-que là clairement ça n'est pas un.

Merci d'avance :)
 

AccroPC2

Fou du PC
Staff
Hello,

Donc disque fait 1To, 80G c'est beaucoup trop peu. Je crois que le seuil est à 15% ( donc à 150G ) et dans les faits, il a raison ton SSD doit toujours avoir entre 15 et 20% de libre.

Bye
 

Dark-Angel66

Grand Maître
Hello,

Donc disque fait 1To, 80G c'est beaucoup trop peu. Je crois que le seuil est à 15% ( donc à 150G ) et dans les faits, il a raison ton SSD doit toujours avoir entre 15 et 20% de libre.

Bye

Et pourquoi faire ? Au final sur les 1To, j'ai 930Go réellement et EN PLUS faut enlever 15% donc au final j'ai un SSD de 790Go :lol:
 

AccroPC2

Fou du PC
Staff
Et pourquoi faire ? Au final sur les 1To, j'ai 930Go réellement et EN PLUS faut enlever 15% donc au final j'ai un SSD de 790Go :lol:

C'est le fonctionnement même d'un SSD si tu veux qu'il garde ses perfs faut pas qu'il soit trop plein, un SSD ne réécrit pas sur une cellule mais sur une cellule "libre".

Bye
 

Patakesse

Gruik Gruik!
Tu as bien 1 To, mais pas 1 Tio. Ce qui fait bien 931 Gio (moins ce que le système de fichier réserve pour sa gestion lors du partitionnement et surtout du formatage). C'est juste que Windows n'affiche pas correctement l'unité (il affiche Go au lieu de Gio alors qu'il compte en binaire).

En binaire, 1 Kio = 1024 octets. En décimal, 1 Ko = 1000 octets (comme 1 kilogramme = 1000 grammes). Avant 1998, on ne comptait qu'en binaire, mais pour coller aux standards, une commission internationale (l'IEC) a décidé de renommer le Go binaire en Gio, et décrété que le Go serait dorénavant l'unité décimale. Un joyeux bordel, toujours pas intégré plus de 20 ans après, la preuve sous Windows qui continue de compter en binaire mais d'afficher l'unité décimale.

Le fait de devoir laisser de l'espace sur un disque est une recommandation qui date des débuts de l'informatique personnelle, à une époque ou les premiers disques étaient très pénalisés par cela, et où des ingénieurs d'IBM et Microsoft avaient décrété qu'il fallait laisser au moins 10% d'espace libre sur le disque, sous peine de sérieuse dégradation des performances. Cela n'a aucun sens aujourd'hui en terme de performances et encore moins sur un SSD.

MAIS :
  • Il vaut mieux laisser de l'espace libre confortable sur un disque mécanique pour la défragmentation, qui sera plus longue et usera plus le disque si l'espace est trop faible.

  • Il faut laisser suffisamment d'espace libre sur le disque système pour que l'OS puisse assurer sa gestion de manière efficace.

  • Tous les systèmes de fichier de ne valent pas en terme de performances. Donc pour certains, il est possible (mais je n'ai pas trouvé d'étude sur le sujet) que laisser peu d'espace libre, et si on a énormément de fichiers, puisse affecter un peu les performances. Mais ça n'est pas une question matérielle.

  • Certains disent que laisser beaucoup d'espace libre sur un SSD, c'est prolonger sa durée de vie (c'était particulièrement vrai pour les premiers SSD). D'autres diront que ça ne sert strictement à rien. C'est une question qui divise et n'a aucun sens tant qu'on ne rentre pas dans les algorithmes secrets des contrôleurs. Certains avancent même qu'il faudrait laisser 25% de libre ! Il faut savoir qu'un SSD (comme un HDD d'ailleurs) n'affiche pas la totalité de sa capacité réelle. Une partie de l'espace de stockage est invisible pour le système et donc l'utilisateur (par exemple un disque de 1 To peut très bien avoir 1,1 To d'espace de stockage en réalité). Cet espace dit "de provision" sert à la gestion du disque (remplacement de blocs défectueux, optimisation de l'usure sur les SSD). C'est le contrôleur intégré qui gère au mieux la mémoire. C'est pourquoi il ne faut jamais défragmenter un SSD, ça n'apporte strictement rien en terme de performances mais ça induit une usure inutile (et donc une petite réduction de sa durée de vie).
Je n'ai pas d'avis tranché sur la question de l'espace libre à laisser. Pour moi les disques (HDD ou SSD) sont des consommables au même titre que le papier de mon imprimante, je me fiche un peu de leur durée de vie (tant qu'elle est raisonnable), d'autant qu'ils sont garantis longtemps et que j'ai une politique de sauvegarde multiple automatique stricte, en plus du fait qu'ils sont en grappe (RAID). Sur les 3 douzaines de disques que je gère en tout (dont la moitié tourne 24h/24), j'en change en moyenne 1 par an, sans jamais faire attention à ces considérations d'espace libre ou autres. Depuis 2017, j'ai eu 2 SSD qui ont rendu l'âme, mais c'était des modèles de petite taille, d'entrée de gamme, ils avaient quelques années et étaient très sollicités quotidiennement (servant de cache réseau dans des serveurs). Ce que je veux dire, c'est qu'en utilisation très intensive (post production film), sans prendre de mesures particulières, les SSD modernes tiennent plusieurs d'années. Les deux plus importants de 2 To sur ma machine principale ont 5 ans et leur santé est encore à 100% selon le logiciel du constructeur, alors qu'ils sont les plus sollicités de la machine et souvent pleins à craquer. Alors s'embêter à "en prendre soin".. :)
 

slide95

Expert
[...]

  • Tous les systèmes de fichier de ne valent pas en terme de performances. Donc pour certains, il est possible (mais je n'ai pas trouvé d'étude sur le sujet) que laisser peu d'espace libre, et si on a énormément de fichiers, puisse affecter un peu les performances. Mais ça n'est pas une question matérielle.
    [...]

Le livre de A S Tanenbaum "Operating Systems, design and implementation" propose une brève étude sur le sujet.

Globalement, la perf d'un ensemble device + système de fichiers se dégreade nécessairement avec le remplissage (il faut chercher les blocs libres). Mais la dégradation se fait essentiellement en écriture, et est exponentielle. Et dépend des algo utilisés par l'OS (mais elle existe toujours).

Bref de façon générique l'impact commence à être mesurable à 50% de remplissage avec les plus vieux systèmes de fichier, et en effet dépasser 90% de remplissage peut ralentir sensiblement les accès en écriture.

Et la dégradation sera alors amplifiée par les phénomènes mécaniques sur un HDD, hors sujet ici.

Mais l'impact est essentiellement sensible en écriture, moins en lecture. Alors pour un disque non stockage, avant d'avoir un vrai ralentissement on peut y aller.

Pour la petite histoire, des systèmes de fichiers ont existé qui défragmentent eux-même (Silicon Graphics XFS par exemple). Ce qui n'est pas sans danger. Et complètement inutile sur un SSD, puisque le but était de minimiser les voyages de la tête de lecture du disque dur.
 

SergioVE

Tout à faire car rien n'est fait.
Malgré une traduction indigne, longue discussion intéressante sur le sujet ici :
 

slide95

Expert
Malgré une traduction indigne, longue discussion intéressante sur le sujet ici :

Le ramasse-miette (garbage collector) d'un SSD utilise de l'espace excédentaire du SSD lui-même, donc le point 2 du lien n'est pas avéré. C'est d'ailleurs pour cela que certains fabricants vendent des 480Go basés sur des puces totalisant 512Go voire plus. Compter de 7% (SSD grand public) à plus de 15% (gammes pro) d'overprovisioning.

Mais pour le reste, il est bon de toujours garder de la marge. En effet, si un jour une mise à jour de sécurité ne pouvait s'effectuer faute de place, vous pourriez le regretter plus fort que prévu.

Quand à l'aspect fragmentation, cela dépend fortement du système de fichiers. FAT fragmente beaucoup, NTFS notablement moins, et des systèmes de fichiers modernes (ext4fs, btrfs, ex-FAT) sont infiniment mieux pensés là-dessus.

Mais un FS plein à 99% sur lequel on ajoute un fichier ne fera pas de miracles.

Les débits en lecture sur un FS fragmenté sont super impactés par les temps d'accès, c'est pourquoi défragmenter est bien plus spectaculaire en terme d'amélioration sur un HDD que sur un SSD.
 

Patakesse

Gruik Gruik!
Je connais bien ces deux sources et j'ai hésité à les citer. Ceux qui recommandent de laisser de l'espace libre se basent sur de vieilles technologies ou de vieux documents. Je ne dis pas qu'ils ont tort, mais les algos des firmwares de contrôleurs de SSD n'ont cessé de s'améliorer depuis pour en optimiser l'usage et réduire l'usure.

L'impact des systèmes de fichier est à mon humble avis totalement négligeable sur un disque connecté en PCIe (NVMe). Si on perds même 10% de vitesse à l'écriture (ce qui est déjà conséquent), ça reste dérisoire (passer de 2,5 Gio/s à 2,25 Gio/s ne fait pas une différence si cruciale que ça pour la plupart des utilisateurs). C'est en tout cas ce que je constate, puisque je fais partie des utilisateurs pour lesquels le NVMe est indispensable. Un rush ARRIRAW 6.5K nécessite un débit constant (en lecture) d'environ 740 Mio/s, impossible à atteindre en Sata. Pour deux rushs lus en même temps, on double le débit. Or que le disque soit quasiment vide ou totalement plein, ça ne change rien de perceptible aux performances, que ce soit en lecture ou en écriture lors du transfert des rushs.

L'impact est sans doute beaucoup plus perceptible sur un disque comprenant des centaines de milliers de petits fichiers, obligeant à la recherche des blocs libres en parcourant les noeuds. Mais encore une fois, ça dépend du système de fichier. Entre un système lent basé sur une table d'allocation (FATxx, exFAT), et un système organisé en arbre comme NTFS, EXT4, ReFS ou ZFS, l'impact n'est pas le même.

Je vous retrouverais l'article qui explique très en détail le fonctionnement d'un SSD et pourquoi il ne faut jamais essayer de défragmenter un tel dispositif. D'ailleurs, il me semble que sous Windows, on ne peut pas défragmenter un SSD, on peut juste faire un TRIM (pour indiquer au contrôleur les blocs non utilisés et qu'il puisse gérer son optimisation).
 

SergioVE

Tout à faire car rien n'est fait.
Cela dit, pour répondre partiellement à la demande de @Dark-Angel66 (car ce ne sera plus jamais en rouge, à lui de gérer) :

[Edit] Pour bien faire, il faudrait modifier la valeur de "System.PercentFull" mais ça fait partie des gestions de propriétés de Windows et c'est au-delà de mes compétences.
 
Dernière édition:

slide95

Expert
En nvme, les transferts sont plus rapides, les chemins de code prennent donc d'autant plus d'importance, au point que Intel suggère maintenant de "contourner" l'OS et de passer en mode polling pour des débits maximum (cf le spdk).

Ce qui se justifie à 100% pour un équipement sur lequel on s'attend à des forts débits 24x7. Mais tel quel le spdk reste en polling, et sans transfert on fait faire de l'attente active (on peut le configurer autrement, mais ce n'est plus optimal en perf).

la preuve, les 10% de "perte" correspondent en fait à un débit "nominal" d'un HDD SATA récent. Ou d'un SSD médiocre.

Mais du coup oui, le débit est tel qu'il est supérieur à beaucoup d'usages. Il n'y a qu'en data center que les nvme sont limite...
 
Vous devez vous inscrire ou vous connecter pour répondre ici.
Derniers messages publiés
Statistiques globales
Discussions
730 098
Messages
6 717 061
Membres
1 586 286
Dernier membre
petitangebleu1977
Partager cette page
Haut