Discussion :

[mm_71]

Je pense que lorsque tu as mis ton gros fichier sur le SSD les autres fichiers n'ont pas été effacés.

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.

[CTJayce]

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.

[callele50]

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.

[Jipété]

Salut,

[...] bien qu'il ne reste presque plus de place sur celui-ci foremeost me remonte une quantité incroyable de fichiers comme si ils étaient restés stockés sous les fichiers actifs et ça dépasse ma compréhension.

Tu pourrais creuser ce point et confirmer/infirmer ?

Car te lire dépasse mon entendement !

Surtout en lisant ça :

Aussitôt que vous constatez la perte de fichiers, arrêtez d'utiliser, autant que faire se peut, le disque dur (ou autre périphérique de stockage) sur lequel a eu lieu la perte. Autrement, vous risquez de ré-écrire par dessus vos fichiers perdus.

[disedorgue]

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.

[transgohan]

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

[Philippe Dpt35]

Voici un petit lien qui laisse comprendre pourquoi les effacements sur SSD ne se font pas:
https://fr.wikipedia.org/wiki/Trim_(informatique)

A la lecture, ça explique pourquoi mais fait se poser encore plus de questions:

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 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é ?

Si l'OS sait, pourquoi l'écriture de bits 0 ne fonctionnerait-il pas puisque c'est fait par le système ?

[Philippe Dpt35]

Je ne connais pas le système de fichier utilisé, mais n'y a-t-il pas de la fragmentation ?

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.

[disedorgue]

A la lecture, ça explique pourquoi mais fait se poser encore plus de questions:



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é ?

Si l'OS sait, pourquoi l'écriture de bits 0 ne fonctionnerait-il pas puisque c'est fait par le système ?

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

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.

[mm_71]

Tu pourrais creuser ce point et confirmer/infirmer ?

Quand j'aurai un moment je ferai une démonstration par l'image dans ce même fil.

Car te lire dépasse mon entendement !

Les résultats obtenus dépassent aussi mon entendement.

[CTJayce]

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

On peut essayer en remplaçant /dev/zero par /dev/random dans les exemples
précédents, ainsi cat /dev/random > tmp_file ou dd if=/dev/random > tmp_file

[Philippe Dpt35]

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

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 !

[chrtophe]

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 ?

[disedorgue]

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

[mm_71]

Quand j'aurai un moment je ferai une démonstration par l'image dans ce même fil.
Les résultats obtenus dépassent aussi mon entendement.

Bon, j'ai refait un test complet et voici le résultat dans un fil qui va être bien chargé.

1: Mon SSD:

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.

Et maintenant c'est ici qu'on s'amuse avec foremost:

Et voilà le résultat !!!!!!!!!!!!!!!!!!!!

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 !

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

[mm_71]

Précédemment j'avais dit:

foremeost me remonte une quantité incroyable de fichiers comme si ils était resté stockés sous les fichiers actifs

Et ce vieux message de 2007:

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

[disedorgue]

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

[CTJayce]

Alors si quelqu'un y comprend quelque chose ? On dirait que mon SSD protège les images comme une poule couve son œuf !

Maintenant c'est clair, cluster ou block d'une très grande taille avec un système
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 ?

[chrtophe]

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

[Philippe Dpt35]

à tester pour en vérifier l'efficacité sur SSD, en l'adaptant aux espaces libres et non à l'effacement de tout le disque par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dd if=/dev/urandom of=/vide

à faire 7 fois minimum, ou réaliser un script pour ce faire comme indiqué.
puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

rm -rf /vide

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é !