Version imprimable
Depuis le début on parle de nettoyer l'espace restant libre sur le disque, pas tout le disque. Donc en effet le disque était presque entièrement rempli le problème est que bien qu'il ne reste presque plus de place sur celui-ci foremeost me remonte une quantité incroyable de fichiers comme si ils était resté stockés sous les fichiers actifs et ça dépasse ma compréhnsion.Citation:
Je pense que lorsque tu as mis ton gros fichier sur le SSD les autres fichiers n'ont pas été effacés.
Vraisemblablement la commande "dd" a mal été utilisée et n'a donc
pas généré le fichier attendu.
Ne manque-t-il pas un paramètre "count" ?
Peut être qu'on peut également envisager quelque chose comme
cat /dev/zero > tmp_file ou dd if=/dev/zero > tmp_file, laisser
tourner jusqu'au trop-plein, supprimer tmp_file et refaire le test de
récupération de fichier.
Bonjour CTJayce, j'ai essayé la commande dd que tu a proposé, la commande foremost récupère toujours autant de données récentes et intact, mais peut-être que la commande marcherait mieux sur un hdd. Je n'est pas encore essayer.
Salut,
Tu pourrais creuser ce point et confirmer/infirmer ?Citation:
Envoyé par mm_71
Car te lire dépasse mon entendement !
Surtout en lisant ça :Citation:
Envoyé par doc ubuntu
Bonjour,
Voici un petit lien qui laisse comprendre pourquoi les effacements sur SSD ne se font pas:
https://fr.wikipedia.org/wiki/Trim_(informatique)
Après, tu peux toujours voir avec la commande hdparm et les options de trim mais cette commande peut-être dangereuse en cas de mauvaise manipulation (perdre des données)...
Bon courage.
Je ne connais pas le système de fichier utilisé, mais n'y a-t-il pas de la fragmentation ?
S'il y a de la fragmentation alors il est normal de retrouver des données, car la partie indiquée comme libre ne recoupe pas la totalité de la mémoire non utilisée car certaines zones fragmentées ont généré des espaces non utilisables (un octet par-ci, un octet par là).
Si beaucoup de fragmentation cela expliquerai la récupération de 500mo alors que le disque indique 50mo de libre.
On pourrait comprendre ainsi qu'il y a en fait plus de 50mo de libre mais que de nombreux méga ne sont pas utilisables à cause de la fragmentation.
Pour illustrer mon propos j'ai déjà eu une défragmentation sous windows XP (il y a un bon nombre d'années) qui a permit de récupérer 1.7Go d'espace sur le disque dur... ;)
A la lecture, ça explique pourquoi mais fait se poser encore plus de questions:Citation:
Envoyé par disedorgue
Si le support ne sait pas, c'est que l'OS lui doit savoir, sinon comment pourrait-on écrire de nouvelles données sans que le support apparaisse très vite comme saturé ?Citation:
En effet, les unités SSD ne savent pas quels blocs sont réellement utilisés et quels blocs sont libres, car elles ne sont pas informées des structures du système de fichier utilisé. Les clusters inutilisés sont donc inconnus du support (les données sont présentes sur le support, mais ne sont plus utilisées par le système d'exploitation, par exemple une corbeille vidée)
Si l'OS sait, pourquoi l'écriture de bits 0 ne fonctionnerait-il pas puisque c'est fait par le système ?
:weird:
Il me semble que les systèmes de fichier Linux ont un mode de fonctionnement qui, contrairement à Windows, ne provoque pas de fragmentation des fichiers. C'est pourquoi les utilitaires de défragmentation sont nombreux sous Windows, mais inexistants sous Linux.Citation:
Envoyé par transgohan
Sur un ssd, il y a un microcontroller, qui pourrait très bien voir que l'on injecte une suite de zéro et qu'au lieu de remplir bêtement ces cellules, ne fait que marqué la/les page(s) comme étant rempli de zéro (ou un autre nombre), ceci juste pour permettre de préservé le matériel de l'usure inutile...Citation:
Envoyé par Philippe Dpt35
Ensuite, on ne sait pas comment est structurée l'arborescence présente sur le disque en question: est-ce une multitude de petit fichiers ou autre chose.
Car dans le cas d'une multitude de petits fichiers, comme par exemple du pire: n fichiers de 1 octet, tu auras n blocs non effacés dans lesquels tu n'auras qu'un seul octet d'invalide vis à vis du fichier précédent qu'il contenait.
Et en plus, je pense que pour réussir à faire le vidage, c'est du cas par cas selon la marque et la version du ssd ne serait-ce que pour bypasser toutes les sécurités contre l'usure qu'aurait pu intégrer le fabricant.
Quand j'aurai un moment je ferai une démonstration par l'image dans ce même fil.Citation:
Tu pourrais creuser ce point et confirmer/infirmer ?
Les résultats obtenus dépassent aussi mon entendement.Citation:
Car te lire dépasse mon entendement !
On peut essayer en remplaçant /dev/zero par /dev/random dans les exemplesCitation:
Envoyé par disedorgue
précédents, ainsi cat /dev/random > tmp_file ou dd if=/dev/random > tmp_file
J'utilise le remplissage des espaces vides par bit 0 avant de faire une compression d'image système construit sur carte SD sur Raspberry Pi. J'ai constaté que la construction à différentes reprises du même système après de très légères modifications me donnait des images compressées pouvant varier de quelques centaines de Mo non justifié par ces modifications. Je n'avais pas encore de réponse à cette curiosité, en voilà une possible !Citation:
Envoyé par disedorgue
L'histoire du Trim n'est pas idiote, mais si les blocs sont marqués utilisables/effaçable et qu'ils ne le sont pas, la commande dd correctement lancée pour générer un gros fichier remplissant le disque va les utiliser lors de l'écriture de celui-ci, et donc remplacer leur contenu.
Voir aussi la remarque sur le remplissage de zéros, mais si on lui demande d'écrire des 0, pourquoi l'OS ne le ferait pas ?
Ce ne sont que des hypothèses: on ne sait pas ce que fait le microcontrôleur derrière...
Et à priori, il existe aussi sur les ssd récents, des flags activables pour des suppressions sécurisé,... mais c'est plus sur la totalité du disque à priori.
Pour moi, ce qu'il faut faire, c'est de travailler l'effacement sur la totalité du disque et non juste sur les espaces libres car l'unité d'un fichier est l'inode dont l'unité est le bloc et dont l'unité est le secteur, donc rien que les fichiers présents conservent des données des anciens fichiers.
Une piste pour ce cas:
-Archivage des fichiers sur un autre disque de ce que l'on veut garder
-Suppression de tous les fichiers
-Un petit coup de hdparm avec les options trim sur tous les secteurs (voir le man hdparm)
-On repose un fs et on redescend l'archive
Bon, j'ai refait un test complet et voici le résultat dans un fil qui va être bien chargé.Citation:
Envoyé par mm_71
1: Mon SSD:
Pièce jointe 430420
Comme on peut le voir très peu d'espace inutilisé.
Ensuite nettoyage et écrasement par bleachbit. Pour être certain j'ai écrasé l'espace libre sur /root et /home, les fichiers d'écrasement ont bien été généré et c'est très long, 10/15 Minutes par répertoire.
Pièce jointe 430422
Et maintenant c'est ici qu'on s'amuse avec foremost:
Pièce jointe 430428
Et voilà le résultat !!!!!!!!!!!!!!!!!!!!
Pièce jointe 430430
Et bien sur cette tartine me génère des vignettes dans le cache et on peut faire encore pire! On relance la même commande foremost et cette fois c'est l'apocalypse !
Pièce jointe 430433
Le cache des vignettes s'en trouve saturé et le gestionnaire de fichier se vautre lamentablement.
Voyons maintenant sur d'autres types de fichiers:
.avi Rien de récupérable, une dizaine de fichiers de 18.1 Mo inexploitables.
.jpg 1587 images pour un poids de 408,9 Mo toutes utilisables et dont certaines remontent à l'an passé et d'autres dont je n'ai aucun souvenir.
.pdf 68 fichiers pour 14,5 Mo qui remontent à l'an passé et un en Russe dont je ne sais d'ou il sort ??!!
.mkv et .txt n'est pas géré par foremost. C'est dommage.
Alors si quelqu'un y comprend quelque chose ? On dirait que mon SSD protège les images comme une poule couve son œuf !
PS: Ça serait bien d'éloigner un peu le bouton 'prévisualisation' du bouton 'poster la réponse'.
Précédemment j'avais dit:
Et ce vieux message de 2007:Citation:
foremeost me remonte une quantité incroyable de fichiers comme si ils était resté stockés sous les fichiers actifs
https://forum.ubuntu-fr.org/viewtopic.php?id=119496
Semble le confirmer:
"Pourquoi penses-tu que l'espace libre représente l'emplacement des fichiers effacés ?
Dans une grande part, l'espace occupé par un fichier effacé est réutilisé lors de la création d'autres fichiers (très schématiquement). Il faudrait voir aussi l'emplacement exact occupé par les fichiers effacés. "
Mes hypothèses sur les microcontrôleurs semblent se confirmer.
Voici un petit lien qui explique autant que possible comment un ssd fonctionne (désolé, c'est en anglais) :
https://www.extremetech.com/extreme/...w-do-ssds-work
Maintenant c'est clair, cluster ou block d'une très grande taille avec un systèmeCitation:
Envoyé par mm_71
de fichier qui conserve la trace des fichiers effacés, un logiciel de récupération
de données qui récupère aveuglément tout, avec peut-être la capacité de reconstruire
l'entête des fichiers précédemment effacés (grâce à leurs extensions) et tu te retrouves
avec un résultat tout à fait exploitable. N'y a-t-il pas un utilitaire pour supprimer les
données orphelines du système de fichier ?
J'ai regardé vite fait.
Regarder la commande fstrim.
Il semble recommandé d'utiliser des outils constructeur, qui propose un effacement total du disque. De ce que j'en ai compris, cela marque tous les blocs comme effacé. Partedmagic est également recommandé.
à tester pour en vérifier l'efficacité sur SSD, en l'adaptant aux espaces libres et non à l'effacement de tout le disque par
à faire 7 fois minimum, ou réaliser un script pour ce faire comme indiqué.Code:dd if=/dev/urandom of=/vide
puis
On peut encore jouer sur la taille des blocs par bs, mais outre que ça fera fortement varier le temps de l'opération, il faut voir si ça joue significativement sur son efficacité !Code:rm -rf /vide
