Discussion :

[gangsoleil]

Bonjour,

C'est drôle, j'ai déjà eu ce genre de discussions il y a quelques années, je vais essayer d'apporter ma pierre à l'édifice, tout en limitant les bêtises -- en sachant que je maîtrise beaucoup mieux le fonctionnement d'un disque à plateau que celui d'un SSD.
Le 2nd lien de diserdogue est vraiment pas mal, même si je reconnais qu'il ne donne pas toutes les réponses.

Tout d'abord, il ne faut pas oublier que la taille théorique du SSD n'est pas sa taille réelle -- pour une fois, l'acheteur a plus que ce qu'il achète. Cela permet de combler les problèmes de secteurs morts, qui sont inévitables, mais aussi de garder de la place libre pour écrire ailleurs. Et plus vous avez un disque de marque/qualité, plus ce surplus est grand. Ça fait longtemps que je ne fais plus attention à cela, mais ça pouvait ne pas être négligeable sur les petits disque (moins de 128 Go).

Comme l'écriture endommage le SSD (enfin les NAND), le nombre d'écritures sur un SSD est limité au minimum. Notamment, l'effacement physique n'est pas vraiment nécessaire (sauf dans le cas précis qui nous intéresse ici), donc il est souvent omis afin de préserver la durée de vie du disque. Sur un SSD, il vaut mieux ré-écrire les données à côté que de modifier l'existant.

Enfin, il faut considérer que même les logiciels commerciaux qui effacent les données ont eu quelques ratés lors du passage aux SSDs : ils ont fait exactement ce qu'ils faisaient avec les disques à plateau, c'est à dire écrire sur les secteurs "vides" (en fait pas réellement vides mais marqués comme libre), pour effacer réellement la donnée. Cela fonctionne sur un disque à plateau, mais pas sur un SSD. Donc le lien sur le site de Korben ne fonctionne pas pour un SSD -- mais est entièrement valide pour un disque à plateau.

Si même les spécialistes du domaine se sont plantés au début, vous imaginez bien que c'est pas en 2 jours sur un forum que la solution va être trouvée -- je ne dis pas qu'ils sont plus intelligents, mais simplement qu'ils connaissent mieux le sujet que nous, et qu'ils ont eu du mal à trouver une solution d'effacement qui ne pourrisse pas le SSD tout en étant efficace.

Du coup, qu'est-ce que je propose ? Ben pas grand chose malheureusement... Déjà, peut-être faut-il regarder ce que proposent les logiciels d'effacement professionnels pour les SSD, et surtout les limitations qu'ils indiquent. Ensuite, chercher de la littérature sur le sujet, pour trouver comment faire pour avoir un effacement réel sur un SSD. Puis le faire. Ca va sûrement être un peu long, mais c'est à mon sens le seul moyen.

[Philippe Dpt35]

Enfin, il faut considérer que même les logiciels commerciaux qui effacent les données ont eu quelques ratés lors du passage aux SSDs : ils ont fait exactement ce qu'ils faisaient avec les disques à plateau, c'est à dire écrire sur les secteurs "vides" (en fait pas réellement vides mais marqués comme libre), pour effacer réellement la donnée. Cela fonctionne sur un disque à plateau, mais pas sur un SSD. Donc le lien sur le site de Korben ne fonctionne pas pour un SSD -- mais est entièrement valide pour un disque à plateau.

Mais là il ne s'agit pas d'écrire des 0 dans les secteurs vides, mais de remplir de données aléatoires les espaces libres en écrivant dans un fichier. C'est une demande d'écriture légitime de fichier de la part de l'OS, que le microcontrôleur du SSD n'a aucune raison de refuser me semble-t-il.

[gangsoleil]

Mais là il ne s'agit pas d'écrire des 0 dans les secteurs vides, mais de remplir de données aléatoires les espaces libres en écrivant dans un fichier. C'est une demande d'écriture légitime de fichier de la part de l'OS, que le microcontrôleur du SSD n'a aucune raison de refuser me semble-t-il.

C'est bien ce qui est fait : le fichier est écrit, pour de vrai, sur le disque.

Sauf que sur un SSD, le fait d'écrire sur un secteur vide est plus rapide, et moins consommateur et moins destructeur, que de ré-écrire un secteur déjà écrit et noté comme potentiellement réutilisable.

Donc l'écriture sur secteur vide est toujours privilégiée par rapport à l'effacement réel d'un bloc.

[Philippe Dpt35]

Donc l'écriture sur secteur vide est toujours privilégiée par rapport à l'effacement réel d'un bloc.

Mais là comme on écrit jusqu'à saturation de l'espace libre, il devrait normalement finir par écrire sur les secteurs non vides, en toute logique.

[transgohan]

Mais là comme on écrit jusqu'à saturation de l'espace libre, il devrait normalement finir par écrire sur les secteurs non vides, en toute logique.

Oui mais pas forcément tous, il peut boucler sur certains secteurs et en laisser d'autres. De plus il ne faut pas oublier qu'il y a plus de secteur que d'espace utilisable.
Cela dépend de l'algorithme du constructeur.

Si on force le trait c'est comme de dire que tu as un bac de 1024m² (espace réel du SSD).
Que tu n'avais de l'eau que pour remplir 256m² (limitation constructeur du SSD).
Que l'arroseur était l'algorithme qui décidait quel portion remplir.
Il faudrait un sacré paquet d'écriture en fonction de l'algo pour repasser sur les 1000m².

[mm_71]

un bac de 1024m²

Je crois qu'il manque une dimension à ton bac...

A part ça au vu des réponses je commence à comprendre le pourquoi du comment mais quand même pour un SSD de seulement 32 Go qui subit plusieurs fois par semaine des écritures / effacements lors des mises à jour de l'OS et ou j'envoie aussi mes téléchargement avant de les déplacer vers un autre emplacement qu'il subsiste encore des fichiers datant de qq. années me laisse rêveur.

Je suppose que l'option "écraser les fichiers" qui consiste à remplacer tout le contenu des fichiers par des 0 avant de l'effacer merdoie aussi et que les 0 sont écrits à côté du fichier cible ?

Un jour où l'autre je vais passer en Mint 19 et refaire une installation propre "from scratch". J'en profiterai pour faire des test avec le SSD vide, re-partitionné, formaté et férocement écrasé et mettrai les résultats ici.

[gangsoleil]

Je suppose que l'option "écraser les fichiers" qui consiste à remplacer tout le contenu des fichiers par des 0 avant de l'effacer merdoie aussi et que les 0 sont écrits à côté du fichier cible ?

Je dirai que oui -- de mémoire, c'est que faisaient les premiers logiciels d'effacement de disque durs SSD, et c'est entre autre à cause de ça qu'ils étaient considérés comme buggés.

[disedorgue]

@mm_71: Dans tes tests, on voit que tu attaque sda1 pour les remplissages et tu attaques sda pour la récupération...
Et sur le bout d'image que l'on a, on voit un blanc assez conséquent non pris pour sda1: c'est peut-être ça la partie qui ne bouge pas depuis des années...

[mm_71]

Je dirai que oui -- de mémoire, c'est que faisaient les premiers logiciels d'effacement de disque durs SSD, et c'est entre autre à cause de ça qu'ils étaient considérés comme buggés.

On peut donc en conclure:
1: Si on ne veut pas risquer de surprise ne jamais revendre son ordinateur avec les disques d'origine.
2: Si on utilise des données sensibles toujours le faire sur un support amovible sans lien avec le système principal.
3: Cesser de croire au père noêl et aux logiciels miraculeux.

[mm_71]

@mm_71: Dans tes tests, on voit que tu attaque sda1 pour les remplissages et tu attaques sda pour la récupération...
Et sur le bout d'image que l'on a, on voit un blanc assez conséquent non pris pour sda1: c'est peut-être ça la partie qui ne bouge pas depuis des années...

Mais sda caractérise le disque physique et sda1 la partition qui y est créée, comme il n'y a qu'une partition je ne pense pas que ça change quoi que ce soit. Le blanc dont tu parles caractérise l'espace encore disponible sur la partition (3.86 Go ) je ne vois pas ou il pose problème ?
Pour les remplissages c'est bleachbit qui s'en occupe et il travaille sur les répertoires ( Dans mon cas j'ai donné /root et /home ) et c'est l'espace blanc qu'il est sensé remplir, rien d'autre.
Et pour la récupération je n'ai posté qu'une seule image mais dans le doute je l'ai faite sur /dev/sda et sur /dev/sda1 avec exactement les mêmes résultats.

[Jipété]

Bonjour,

grosse flemme de relire les trois pages qui précèdent, alors je passe juste l'info sur laquelle je viens de tomber (en faisant des recherches sur autre chose), et en mettant en gras ce qui m'a fait penser à cette discussion :

Bad Tool for Making Sparse Images: cat /dev/zero > /mnt/bigfile

NOTE: This method is not recommended by the ext4 developers!

While it is possible to zero out unused disk blocks by writing a lot of zeroes to a file and then deleting it, this is not a recommended way to do this! First of all, building such a huge file requires the construction of an extent tree, which means that the filesystem ends up allocating disk blocks in order to zero unused disk blocks. This is not efficient, and if you've not mounted with -o discard, the extent tree blocks are never zeroed. This problem gets much worse on any filesystem that doesn't use extents (ext2/3). The second problem is that ext4 remembers which block groups have never had blocks allocated, which enables e2fsck to skip checking whether the block group's free block count corresponds to the block bitmap. This slows down e2fsck.

Kristian Hermansen mentioned this method in a G+ thread.

source