# Multiboot sur SSD **URL:** \ **Category:** Support Debian\ **Created:** [Octobre 28, 2018, 10:08 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867 "2018-10-28T22:08:32Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Lien\_Rag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/ba8739/32.png) [@Lien\_Rag](https://www.debian-fr.org/u/Lien_Rag)\ **Post date:** [Octobre 28, 2018, 10:08 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/1 "2018-10-28T22:08:32Z")
Je veux installer un dual boot Debian Stretch/Mint Tara (pour les outils tablettes) sur un SSD (les données seront sur un HDD secondaire) mais : - Comment être sûr que les clés privées SSH et GPG ne seront jamais écrites sur le SSD (vu qu’un SSD ne s’efface jamais)? - Comment gérer la /home puisque le but c’est quand même d’avoir le maximum de trucs en commun (du genre les bookmarks de Firefox ou Palemoon, la liste RSS de Liferea, etc.)? Du symlink normalement, mais quoi symlinker où? - 250 Go de SSD c’est trop pour juste deux OS (je pense mettre 50 Go pour Debian de façon à avoir de la marge, et peut-être 15 Go pour Mint). Je mets quoi d’autre dessus? Une Debian Buster, une Arch, une Debian kBSD, une Slitaz, peut-être une Debian SID et une LFS (ça n’engendre pas trop de réécritures?), ça sert à quelque chose de tenter l’exotique comme The HURD ou Haiku? Ou même Slackware ou Gentoo? - Vu que le SSD est séquentiel, qu’est-ce que je dois mettre en premier? Debian (que j’ai l’intention d’utiliser plus souvent)? - Grub peut booter des ISOs, c’est une bonne idée de mettre les ISO des trucs que je veux éventuellement tester? Où dans ce cas (sur quelle partition je veux dire)? - On est d’accord que la swap est commune à tous les OS? NB: Il me semblait bien que j’avais créé un sujet là-dessus il y a longtemps mais pas moyen de le retrouver? ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Octobre 29, 2018, 6:44 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/2 "2018-10-29T06:44:22Z")
> [@Lien\_Rag](#): > > Comment être sûr que les clés privées SSH et GPG ne seront jamais écrites sur le SSD (vu qu’un SSD ne s’efface jamais)? Simplement en les installant pas dessus, encore heureux que tu est la possibilité de monter le répertoire te servant à tes clé ou bon te semble, mais mettre des clé SSH et GPG (facilement révoquable) ailleurs qu’a leur endroit habituel est tout de même possible. > [@Lien\_Rag](#): > > Comment gérer la /home puisque le but c’est quand même d’avoir le maximum de trucs en commun (du genre les bookmarks de Firefox ou Palemoon, la liste RSS de Liferea, etc.)? Du symlink normalement, mais quoi symlinker où? Il est possible de partager la partition home, mais fortement non recommander pour es profils utilisateur, c’est vite le bordel à trier et maintenir. Personnellement je ne vois pas d’intérêt à faire du multiboot mis à part avec deux système différent tel qu’avec du BSD ou du Windows. > [@Lien\_Rag](#): > > 250 Go de SSD c’est trop pour juste deux OS (je pense mettre 50 Go pour Debian de façon à avoir de la marge, et peut-être 15 Go pour Mint). Je mets quoi d’autre dessus? Une Debian Buster, une Arch, une Debian kBSD, une Slitaz, peut-être une Debian SID et une LFS (ça n’engendre pas trop de réécritures?), ça sert à quelque chose de tenter l’exotique comme The HURD ou Haiku? Ou même Slackware ou Gentoo? Encore une fois aucun intérêt, autant faire de la virtualisation via n’importe quel hyperviseur installable sur Debian et pouvoir bricoler depuis un seul et même OS. > [@Lien\_Rag](#): > > Vu que le SSD est séquentiel, qu’est-ce que je dois mettre en premier? Debian (que j’ai l’intention d’utiliser plus souvent)? Aucun rapport avec les ancien disque mécanique l’accès est égal au données, c’est ton cache qui fera que l’accès à certains blocs sera plus rapide. > [@Lien\_Rag](#): > > Grub peut booter des ISOs, c’est une bonne idée de mettre les ISO des trucs que je veux éventuellement tester? Où dans ce cas (sur quelle partition je veux dire)? La virtualisation encore une fois sera sans doute une méthode pour tester plus simple, voir encore plus simple, les système LIVE, se chargeant en mémoire. > [@Lien\_Rag](#): > > On est d’accord que la swap est commune à tous les OS? Pas obligatoirement, mais j’ai du mal à voir l’intérêt de ne pas utiliser une SWAP commune avec plusieurs système, si tu doit redémarrer la machine pour changer de système. ---
**Author:** ![Lien\_Rag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/ba8739/32.png) [@Lien\_Rag](https://www.debian-fr.org/u/Lien_Rag)\ **Post date:** [Octobre 29, 2018, 4:35 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/3 "2018-10-29T16:35:36Z")
Je ne suis pas sûr d’avoir assez de RAM pour une virtualisation correcte (j’ai 6 Go, et pour des usages intensifs c’est à peine suffisant), et surtout j’ai 250 Go sur le SSD et pas envie de le cramer avec des données qui devront être écrites et réécrites (par contre si y’a des trucs qui ne demanderont pas 10 000 réécritures ça peut valoir la peine, j’avoue ne pas avoir en tête ce que ça peut être), donc facilement 150 Go qui ne seront pas utilisés si je ne multiboote pas. Donc ça ne me coûte rien de faire du multi-boot, et ça me permet d’avoir un truc qui marche (Debian stable), un truc qui a les outils tablettes (Mint), un truc à jour (Arch)… La question de la place sur le disque est lié à la résilience du truc; si j’ai bien compris quand une cellule crame tout ce qui est avant cette cellule reste lisible et tout ce qui est après est mort? Dans ce cas faut-il mettre Debian Stretch en premier (pour qu’il reste lisible si quelque chose meurt) ou après Mint, Buster, et Arch (puisque je vais l’utiliser plus que les autres, et donc qu’il risque de cramer en premier)? Je comprends quand tu dis que les avantages du multiboot sont limités, mais est-ce qu’il y a des inconvénients dans la situation où je suis? Pour le HDD est-ce que je peux m’amuser avec des systèmes de fichier exotiques ou je mets une seule partion en ext4? Y’a un risque avec des partitions ZFS ou autres? Pour les clés, justement est-ce qu’elles sont uniquement en /home et en /tmp (et donc la /home sur le HDD et la /tmp en tmpfs) ou est-ce qu’il y a d’autres répertoires que j’ai intérêt à mettre sur le HDD (genre /usr/local ou chaipakoi)? D’ailleurs /var/log n’est-il pas mieux également sur le HDD pour limiter le nombre d’écritures sur le SSD? Y’en a d’autres à mettre sur le HDD pour limiter les écritures? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Octobre 29, 2018, 7:57 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/4 "2018-10-29T19:57:01Z")
> [@Lien\_Rag](#): > > Comment être sûr que les clés privées SSH et GPG ne seront jamais écrites sur le SSD (vu qu’un SSD ne s’efface jamais)? En principe les SSD possèdent une fonction d’effacement (« secure erase ») qui est censé tout effacer, même les blocs masqués. Evidemment, il faut faire confiance au fabricant pour implémenter correctement cette fonction. Sinon, il faut que l’emplacement où sont stockées les clés privées sur le disque dur ou dans un volume chiffré. Concernant l’éventalité que les clés se retrouvent dans le swap, il me semble que les programmes bien écrit qui manipulent des clés privées indiquent au noyau de ne pas swapper les zones de mémoire contenant des clés. Dans le doute, on peut mettre en place un swap chiffré à clé aléatoire renouvelée à chaque démarrage. > [@Lien\_Rag](#): > > Vu que le SSD est séquentiel, qu’est-ce que je dois mettre en premier? Debian (que j’ai l’intention d’utiliser plus souvent)? Comment ça, séquentiel ? > [@Lien\_Rag](#): > > Grub peut booter des ISOs, c’est une bonne idée de mettre les ISO des trucs que je veux éventuellement tester? Où dans ce cas (sur quelle partition je veux dire)? GRUB ne peut pas amorcer n’importe quel type d’image ISO, mais seulement celles contenant un noyau Linux ou autre que GRUB sait charger. On ne peut pas l’utiliser pour chaîner le chargeur d’amorçage présent dans l’image ISO, car ledit chargeur ne s’attend pas à être lancé depuis une image. D’autre part tous les systèmes présents sur les imagtes ISO ne fonctionnent pas forcément avec un fichier image ; l’installateur Debian inclus dans les images ISO d’installation ne peut pas lire un fichier image ISO, mais seulement un disque entier ou une partition. > [@Lien\_Rag](#): > > On est d’accord que la swap est commune à tous les OS? C’est comme tu veux. Mais évite de marquer le swap existant comme utilisé par le second système lors de son installation, car les installateurs ont la fâcheuse tendance à reformater le swap, ce qui change son UUID et l’empêche d’être reconnu par son propriétaire créateur. Ou bien utilise LVM, qui évite d’utiliser les UUID. Pense aussi que l’hibernation d’un système pour redémarrer avec l’autre est impossible avec un swap partagé. > [@Lien\_Rag](#): > > La question de la place sur le disque est lié à la résilience du truc; si j’ai bien compris quand une cellule crame tout ce qui est avant cette cellule reste lisible et tout ce qui est après est mort? D’où sors-tu un truc pareil ? Jamais entendu parler, et je doute que ce soit vrai. > [@Lien\_Rag](#): > > D’ailleurs /var/log n’est-il pas mieux également sur le HDD pour limiter le nombre d’écritures sur le SSD? Il n’y a pas tant d’écriture dans /var/log, en tout cas rien qui soit insoutenable pour un SSD récent. ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Octobre 29, 2018, 8:00 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/5 "2018-10-29T20:00:21Z")
> [@Lien\_Rag](#): > > La question de la place sur le disque est lié à la résilience du truc; si j’ai bien compris quand une cellule crame tout ce qui est avant cette cellule reste lisible et tout ce qui est après est mort? Oh : Que non. Heureusement que ce n’est pas comme avec une bande magnétique Comme c’était il y a 40 ans, cela ne nous rajeunit pas.On était content quand on avit écrit 180 Mo. Pourrait-on savoir où vous avez lu ce genre de bêtises ? > [@Lien\_Rag](#): > > Dans ce cas faut-il mettre Debian Stretch en premier (pour qu’il reste lisible si quelque chose meurt) ou après Mint, Buster, et Arch Ce n’est pas le cas. Je vous conseille de vous renseigner sur LVM. Et pour que le gestionnaire d’usure ( wear levelling) intégré dans le contrôleur du SSD puisse bien travailler, simplement prévoir de ne pas utiliser l’espace à plus de 80%. > [@Lien\_Rag](#): > > D’ailleurs /var/log n’est-il pas mieux également sur le HDD pour limiter le nombre d’écritures sur le SSD? Comme cel ? ```auto fp2@debpacha:~$ df -hT /var/log Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur /dev/mapper/pacha_vg-var_lv xfs 4,0G 1,5G 2,5G 38% /var fp2@debpacha:~$ fp2@debpacha:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 111,8G 0 disk ├─sda1 8:1 0 2G 0 part /boot └─sda2 8:2 0 109,8G 0 part ├─pacha_vg-root_lv 254:3 0 8G 0 lvm / └─pacha_vg-home_lv 254:4 0 24G 0 lvm /home sdb 8:16 0 931,5G 0 disk ├─pacha_vg-swap_lv 254:0 0 12G 0 lvm [SWAP] ├─pacha_vg-var_lv 254:1 0 4G 0 lvm /var ├─pacha_vg-data_lv 254:2 0 128G 0 lvm /data └─pacha_vg-tmp_lv 254:5 0 8G 0 lvm /tmp sr0 11:0 1 1024M 0 rom fp2@debpacha:~$ ``` > [@Lien\_Rag](#): > > Pour les clés, justement est-ce qu’elles sont uniquement en /home et en /tmp Pourquoi une fixation sur de pauvres fichiers qui entrent dans un bloc standard de 4K ? Si vous voulez générer des clés pour SSH robustes vous pouvez lire [Upgrade your SSH keys! · blog.g3rt.nl](https://blog.g3rt.nl/upgrade-your-ssh-keys.html) Au lieu de vous posez des questions hypothétiques, vous pouvez facilement améliorer « la résilience du truc » - installez `keychain` et mettez dans `.bashrc` quelque chose comme ```auto eval `keychain --eval id_rsa id_rsa_legacy id_ed25519` ``` Chaque fois que vous redémarrer vous devrez taper votre phrase de passe (même dans une console tty2 ) une fois pour toutes les consoles. Ceci fait, vous ne pourrez plus oublier cette phrase de passe. - Installez `keepassx` et mettre dans la base de données vos identifiants pour [debian-fr.org](http://debian-fr.org), le site des impôts, de la sécu … ou d’autres secrets . - (optionnel) installez `git` et `etckeeper` et gérez ainsi la configuration du système avec git. Cordialement, Regards, Mit freundlichen Grüßen, مع تحياتي الخالصة * * * F. Petitjean Ingénieur civil du Génie Maritime. « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos) « Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! » Pierre Dac ---
**Author:** ![Lien\_Rag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/ba8739/32.png) [@Lien\_Rag](https://www.debian-fr.org/u/Lien_Rag)\ **Post date:** [Octobre 29, 2018, 8:35 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/6 "2018-10-29T20:35:34Z")
Ben pourquoi la fixation, tout simplement parce que le moment où la clé est en clair est le point faible de la sécurité? Donc il ne faut absolument pas qu’elle soit écrite sur le SSD (faire confiance à un secure-erase qui repose sur du firmware non libre ne me paraît pas une bonne pratique), et je cherche donc à éliminer tous les trous que je connais et à savoir s’il y en a que j’ignore. Je ne comptais pas mettre le swap sur le SSD (oui ça perd la vitesse d’écriture-lecture du SSD et c’est bien dommage, mais ça évite de le cramer également). Je comprends le risque (que j’ignorais) de changer l’UUID de la swap, mais comment j’indique aux systèmes suivant qu’elle est là si je ne l’indique pas à l’installation? Apparemment j’ai effectivement écrit des couenneries à propos du séquentiel, donc ça veut dire que tout le SSD meurt d’un coup (c’est ce que font les clés USB en tous cas)? Effectivement un des problèmes avec le lancement d’ISO par Grub est que ça demande un procédé qui varie pour chaque distribution, mais bon je trouve l’idée sympa quand même. Mais je ne sais toujours pas dans quelle partition les mettre? Pour un portable je n’ai pas particulièrement intérêt à utiliser LVM, il me semble? Pour le wear leveling cela veut dire que sur mon SSD de 250 Go je devrais laisser environ 50 Go libres? Non partitionnés ou répartis dans chaque partition? Et quel serait le partitionnement idéal du HDD alors (et je symlinke quoi vers quoi)? Une partition /home de 1 Go par OS et une partition de données vers laquelle pointent les répertoires Documents, Vidéos etc? Mais pour les fichiers de config je fais comment (histoire d’éviter les conflits de version mais d’avoir quand même la même config - bookmarks, listes RSS, mails etc - partout)? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Octobre 29, 2018, 9:19 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/7 "2018-10-29T21:19:57Z")
> [@Lien\_Rag](#): > > Je ne comptais pas mettre le swap sur le SSD (oui ça perd la vitesse d’écriture-lecture du SSD et c’est bien dommage, mais ça évite de le cramer également). Si tu as si peur d’user ton SSD et puisque ça semble plus important que d’exploiter ses performances, je te suggère de ne pas l’utiliser du tout, ainsi il durera encore plus longtemps. > [@Lien\_Rag](#): > > Je comprends le risque (que j’ignorais) de changer l’UUID de la swap, mais comment j’indique aux systèmes suivant qu’elle est là si je ne l’indique pas à l’installation? ``` man fstab ``` > [@Lien\_Rag](#): > > a veut dire que tout le SSD meurt d’un coup (c’est ce que font les clés USB en tous cas)? Non, pas forcément. Même chose pour les clés USB. Des blocs de mémoire flash se dégradent et sont remplacés par des blocs de réserve. > [@Lien\_Rag](#): > > Pour un portable je n’ai pas particulièrement intérêt à utiliser LVM, il me semble? Je ne vois pas le rapport. > [@Lien\_Rag](#): > > Pour le wear leveling cela veut dire que sur mon SSD de 250 Go je devrais laisser environ 50 Go libres? Non partitionnés ou répartis dans chaque partition? Le SSD réserve déjà environ 10% de sa capacité physique pour ça, et le système de fichiers ext4 réserve 5% de la capacité logique à root par défaut. Avec un bon usage du TRIM/discard, pas besoin de laisser de l’espace non partitionné. ---
**Author:** ![Lien\_Rag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/ba8739/32.png) [@Lien\_Rag](https://www.debian-fr.org/u/Lien_Rag)\ **Post date:** [Novembre 14, 2018, 12:49 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/8 "2018-11-14T00:49:28Z")
> [@PascalHambourg](#): > > Si tu as si peur d’user ton SSD et puisque ça semble plus important que d’exploiter ses performances, je te suggère de ne pas l’utiliser du tout, ainsi il durera encore plus longtemps. C’est évidemment une option, mais il me semble qu’il y a moyen d’utiliser ses performances pour les usages non destructifs tout en en limitant les usages disruptifs, non? C’est bien 10 000 écritures par cellule au maximum un SSD? Avec une swap ça va vite… > [@Lien\_Rag](#): > > Pour un portable je n’ai pas particulièrement intérêt à utiliser LVM, il me semble? > > Je ne vois pas le rapport. LVM n’est pas surtout utile pour rajouter des disques à la volée? Sur un portable ça ne risque pas d’arriver (surtout que j’ai un DD et un SSD donc les deux emplacements pris, et que je la gestion de chacun est différente. Je voudrais me lancer avec au moins une partition Stretch pour commencer (puisque n’ayant pas de windows dans le lot il sera simple de rajouter des partitions ensuite pour les autres OS), à part /home et éventuellement /var/log sur le DD et /tmp en tmpfs, est-ce qu’il y a une partition qui ne doit pas être sur le SSD pour éviter que les clés privées n’y soient un jour écrites? (parce que je n’ai pas tout compris mais je ne crois pas que Keepass fasse quelque chose au niveau de cette vulnérabilité -là; et de ce que je comprends l’impossibilité d’effacer est lié à la physique des SSD et je ne suis pas sûr que le secure erase le fasse réellement, sans compter qu’on ne peut utiliser un firmware propriétaire pour des questions de sécurité - alors que si j’ai bien compris toujours après un shred sur un DD classique même au microscope électronique il n’est plus possible de retrouver des données) ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Novembre 14, 2018, 12:25 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/9 "2018-11-14T12:25:19Z")
> [@Lien\_Rag](#): > > C’est évidemment une option, mais il me semble qu’il y a moyen d’utiliser ses performances pour les usages non destructifs tout en en limitant les usages disruptifs, non? > C’est bien 10 000 écritures par cellule au maximum un SSD? Avec une swap ça va vite… Cela dépendra du type de ssd, si les puces SLC sont bien plus résistantes les puces MLC sont à fuir pour un usage intensif (exemple du cache). Le fait de devoir compter 3bits par cellules augmentera le taux d’écriture sur chaque cellules et amènera à une dégradation de celle-ci bien plus rapide. Par contre le prix étant bien plus accessible, la taille des disques en, MLC et en TLC permet ne règle générale de monter en volume de stockage. Il me semble que la SLC (donc gamme entreprise) sont donnée à 100.000 cycles, mais bon j’ai déjà vue des ssd en fonctionnement sans broncher avec plus de 2PTo d’écritures dans la tronche … en somme avec un ratio de 2to d’écriture par an je crois que tu doit avoisiner les 5ans d’utilisation à quelques mois près. Tout cela reste de toute façon soumis à variation : gamme de SSD, type de puce et la chance ou non de ne pas être dans une série foireuse. Intel optane est fait pour justement booster les performance du traitement CPU à très bas niveau (je suis pas sûr de ça mais il me semble que le système d’exploitation n’a pas connaissance de la techno optane), et pourtant ça existe bien et niveau écriture il doivent prendre très cher … ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Novembre 14, 2018, 1:25 UTC](https://www.debian-fr.org/t/multiboot-sur-ssd/77867/10 "2018-11-14T13:25:42Z")
> [@Lien\_Rag](#): > > C’est bien 10 000 écritures par cellule au maximum un SSD? Non. Ça dépend du type de mémoire flash (SLC, MLC…) et d’autres paramètres comme la sophistication du contrôleur intégré du SSD et l’usage qui en est fait. > [@Lien\_Rag](#): > > Avec une swap ça va vite Pas tellement, non. Tu as déjà mesuré le volume d’écriture dans le swap ? > [@Lien\_Rag](#): > > LVM n’est pas surtout utile pour rajouter des disques à la volée? Pas seulement. Son utilité première est la gestion des volumes logiques sans les contraintes des partitions qui doivent être contigues. On peut ajouter la gestion des instantanés (snapshots), l’allocation fine (thin provisioning)… > [@Lien\_Rag](#): > > Je voudrais me lancer avec au moins une partition Stretch pour commencer (puisque n’ayant pas de windows dans le lot il sera simple de rajouter des partitions ensuite pour les autres OS) Exemple typique d’utilisation où LVM peut se révéler utile. > [@Lien\_Rag](#): > > de ce que je comprends l’impossibilité d’effacer est lié à la physique des SSD Plutôt à la stratégie d’allocation de la mémoire flash par le contrôleur intégré. Sur un disque dur, quand on réécrit dans un bloc logique les nouvelles donnés sont normalement écrites dans le même bloc physique, écrasant les anciennes données. L’exception est quand le contrôleur a détecté que le bloc physique était « instable », et remappe le secteur logique dans un bloc physique de réserve. Sur un SSD, il faut effacer un bloc de mémoire flash avant de pouvoir y écrire. L’effacement étant une opération longue et usante et la taille d’un bloc d’effacement étant supérieure à la taille d’un bloc logique, le contrôleur intégré d’un SSD moderne écrit systématiquement les nouvelles données dans un nouveau bloc physique effacé à l’avance, et marque les anciennes comme obsolètes. De temps en temps, un ramasse-miette (garbage collector) efface les blocs contenant des données obsolètes afin de les préparer à l’écriture. Dans l’intervalle, les anciennes données restent présentes dans la mémoire flash, bien que non accessibles par l’interface du SSD.