Déplacer un fichier entre deux disques sur un SSD - sera-t-il copié?

18

Lorsque vous déplacez un fichier sur un lecteur, le fichier n'est pas copié et supprimé. Le tableau qui fait référence aux fichiers vient d'être mis à jour. Et pour autant que je sache, ce n'est pas le cas sur 2 disques sur un disque dur. Mais les SSD sont différents, il n'y a pas d'espace physique dédié à chaque disque. ( source )

Ma question est donc de savoir ce qui se passe lorsqu'un fichier est déplacé d'un lecteur à un autre sur le même SSD, les octets sont-ils copiés et l'original supprimé, ou une table est-elle mise à jour, détruisant ainsi le SSD moins?

Il y a déjà une question en double ici . Mais les deux réponses affirment:

chaque partition aura sa propre zone physique du lecteur pour elle-même

et

Le partitionnement d'un disque dur désigne en fait des régions physiques pour chaque partition. [et dans un commentaire:] Le SSD est toujours un disque dur, il n'a tout simplement pas de disque.

Pour autant que je sache, c'est faux. Voyez ici .

Alors, quelqu'un qui en sait plus sur les SSD peut-il me dire s'ils ont raison dans leur évaluation malgré leur erreur?

ispiro
la source
14
La réponse acceptée est juste: chaque partition possède son propre système de fichiers indépendant. Chaque système de fichiers décide lui-même comment il utilise les blocs qui lui sont attribués. Pour faire ce que vous proposez, le micrologiciel des disques SSD, les systèmes de fichiers et les outils utilisateur comme Linux mvdevraient coopérer, mélangeant considérablement les couches d'abstraction.
Kamil Maciorowski
2
@Kamil: Si le système d'exploitation le mettait en œuvre, il mvfaudrait en fait moins que ce qu'il fait actuellement, je suppose. (Autrement dit, le système d'exploitation aurait juste besoin de s'assurer qu'un système de fichiers croisé rename () réussit au lieu d'échouer comme cela se produit actuellement.)
user1686
16
"2 disques sur [un SSD / HDD]" - Je pense que vous voulez dire 2 systèmes de fichiers ou 2 partitions sur un SSD / HDD. N'oubliez pas que le dernier "D" dans les deux acronymes est "Drive", donc vous dites 2 lecteurs sur 1 lecteur, ce qui n'a pas de sens.
JoL
1
Prenons par exemple la boîte de dialogue Gestion des disques. Il indique Change Drive Letter and Pathsen référence à une partition / volume.
ispiro
4
@ispiro Est-ce sur Windows? Semble être un moyen affreux de confondre les utilisateurs. Je peux seulement deviner qu'ils ont trouvé le terme «lettre de lecteur» avant que les partitions de lecteur ne soient implémentées, puis ils ont fini par représenter les partitions de lecteur en tant que «lecteurs» autonomes. Alors maintenant, vous pouvez avoir plusieurs "disques" Windows représentant les partitions d'un disque matériel ...
JoL

Réponses:

38

Pour autant que je sache, c'est faux

La description citée est à moitié correcte, à moitié fausse. Mais c'est aussi à moitié faux pour les disques durs.

Le partitionnement d'un lecteur désigne des régions logiques pour chaque partition. Le système d'exploitation ne se soucie pas du tout des emplacements physiques - il demande simplement au lecteur de "lire le bloc logique # 31415926" et le lecteur lui-même décide de l'emplacement des données. Cela fonctionne de la même manière pour la mémoire magnétique et la mémoire flash.

C'est en fait la même chose qu'avec les disques durs des 20 à 25 dernières années: bien que les premiers systèmes d'exploitation utilisaient des emplacements physiques de cylindre / culasse / secteur, cela fait maintenant longtemps. Vous ne savez pas exactement où se trouve le plateau LBA # 1234. Les disques durs remappent même automatiquement les secteurs physiques défectueux, de sorte que le même LBA peut soudainement être lu à partir d'une zone physique complètement différente - tout comme avec les SSD.

Ainsi, avec les disques durs et les SSD, le système d'exploitation ne dispose que d'une gamme de LBA (par exemple 0–999999) pour lire et écrire des données. Le but du partitionnement est d'y allouer des sous-plages - par exemple, la partition A obtient 10–499999, la partition B obtient 500000–999999. Chaque partition a un système de fichiers indépendant, et les systèmes de fichiers à l'intérieur de chaque partition ne peuvent pas référencer des données en dehors d'elle - ils ne peuvent pas franchir les limites de la partition. (Par exemple, la partition A ne peut pas avoir de fichier dont les données sont conservées dans le secteur # 600000.)

Par conséquent, tous les fichiers se déplaçant de l'un à l'autre doivent être copiés dans leur intégralité.

(Cela dit, en théorie, le système d'exploitation peut être en mesure de demander au disque lui-même de dupliquer les données d'une zone à une autre (par exemple, "copier LBA # 1234 vers # 567890")), sans avoir à le copier dans la mémoire principale, puis à revenir, et bien sûr, cela contournerait complètement les limites de la partition. Cela pourrait utiliser la "couche de traduction flash" du SSD, par exemple. Mais dans la pratique, à ma connaissance, cela ne se fait pas.)

user1686
la source
Je suppose que tu as raison. Cependant, notez qu'il y est une autre option. Le lecteur pourrait décider que le secteur # 001 sur le lecteur # 1 basculerait désormais avec le secteur # 123 dans le lecteur # 2 (c'est-à-dire que le secteur # 001 sur le lecteur # 1 fera désormais référence aux données physiques qui étaient auparavant appelées secteur # 123 dans lecteur # 2) déplaçant ainsi le fichier sans avoir à copier les octets. Le déplacement d'une To de données peut donc en principe être quasi instantané.
ispiro
15
Le lecteur ne connaît pas les fichiers ou les systèmes de fichiers et ne peut donc pas prendre de telles décisions par lui-même. Il doit recevoir une demande du système d'exploitation pour que cela se produise. Comme je l'ai déjà mentionné dans le dernier paragraphe, c'est certainement techniquement possible, mais les systèmes d'exploitation ne se soucient généralement pas de cela pour les copies de systèmes de fichiers croisés, et je doute qu'ils le fassent également pour les copies de systèmes de fichiers (le plus souvent, cela se fait au niveau FS).
user1686
6
Certains disques SSD implémentent une déduplication au niveau des blocs. Par exemple, Sandforce ( en.wikipedia.org/wiki/SandForce#Technology ) a été l'un des premiers à implémenter cela et leurs contrôleurs ont fait leur chemin dans les produits de plusieurs fabricants de SSD. Les contrôleurs Sandforce avaient un facteur "d'amplification d'écriture" inférieur à un - ce qui signifie qu'ils ont écrit moins de données sur le stockage flash que ce que le système d'exploitation a envoyé au lecteur. A titre de comparaison, les SSD ont généralement un facteur d'amplification d'écriture supérieur à un.
hojusaram
2
@hojusaram: Certes, mais il s'agit toujours d'une déduplication post-factum - réduisant les écritures flash, mais les données sont toujours lues, copiées du disque dans la mémoire du système d'exploitation, puis de nouveau dans le contrôleur de disque. Je pense que ce que signifie ispiro est l'équivalent SSD de "reflink" ou "copy on write" (par exemple cp --reflink) que le système d'exploitation pourrait explicitement demander au disque de réaliser seul.
user1686
1
Il serait intéressant de découvrir comment APFS gère cela, car les limites de la partition ne sont plus fixes, elles peuvent être modifiées sans intervention de l'utilisateur.
Tetsujin
9

Ce qui se passe lorsque les données sont écrites sur un disque SSD mérite plusieurs articles (bon résumé ici ), car il est très compliqué et dépend de la technologie sous-jacente. L'histoire courte est que les SSD en général ne peuvent pas écrire zéro bit dans la mémoire. Au lieu de cela, ils doivent mettre à zéro (effacer) toute une section de mémoire, puis ils peuvent stocker des données après cela en les écrivant simplement. Généralement, ces jours-ci, ils écrivent des blocs de 512 octets mais effacent une page de 8 blocs, ce qui correspond à 4096. Cela, et le fait que chaque cycle d'écriture / effacement entraîne une certaine usure physique de la mémoire et que la mémoire finit par s'user, rend les SSD très différents que de faire tourner des disques durs magnétiques.

Mis à part cela, les disques SATA (et les disques AFAIK SAS) n'implémentent pas de commande native pour copier les données d'un secteur à un autre. (Ou du moins, rien dans les spécifications SATA ou SAS ne l'exige, donc le système d'exploitation ne peut pas compter sur une telle commande étant disponible.) Ainsi, une copie de fichier sur une partition impliquera la lecture des données d'un secteur de lecteur dans la mémoire hôte, puis l'écriture il revient sur le lecteur dans un secteur différent.

En effet, en ce qui concerne le système d'exploitation, un lecteur est un ensemble de secteurs logiques numérotés, et tout ce qu'il peut faire est de lire des secteurs et d'écrire dans des secteurs. Le système d'exploitation ne peut pas dire au lecteur de remapper les secteurs.

De plus, le système de fichiers (HFS +, NTFS, ext3, etc.) est un ensemble de structures de données qui imposent l'ordre sur un ensemble de blocs logiques. Ces structures de données implémentent des "fichiers", "noms de fichiers", "répertoires", "autorisations", etc. Donc, oui, lorsque vous déplacez un fichier d'un répertoire à un autre, il n'est pas copié; seules les données du système de fichiers indiquant dans quel répertoire se trouve le fichier sont mises à jour.

Le concept d'une partition est qu'il s'agit d'un ensemble de secteurs logiques sur le disque revendiqué par un système de fichiers unique. Le corollaire à cela est qu'un système de fichiers peut ne pas accéder aux secteurs en dehors de sa partition. Il s'agit en grande partie d'une fonction de sécurité, mais elle découle également du fait que les structures de données du système de fichiers sont toutes construites autour de la prise en compte de chaque secteur du lecteur appartenant au système de fichiers, et il n'est pas trivial d'ajouter ou de supprimer des secteurs à ces structures. C'est pourquoi vous devez exécuter des routines spéciales pour ajuster la taille d'une partition et aussi pourquoi les systèmes de fichiers insistent pour s'exécuter sur un ensemble contigu de secteurs.

Il est donc peu pratique et dangereux d'implémenter une copie de fichier en transférant simplement des secteurs d'un système de fichiers à un autre. Sur un lecteur magnétique en rotation, ce serait également un cauchemar pour les performances, car bien que le lecteur fasse des exceptions pour les secteurs défectueux, il prévoit généralement que les secteurs soient physiquement situés de manière à optimiser la vitesse de lecture et d'écriture des numéros numérotés consécutivement. secteurs.

De plus, 2 systèmes de fichiers peuvent ne pas stocker les données de fichiers de la même manière sur le disque, ce qui signifie que l'échange de secteurs ne fonctionnerait pas même si c'était pratique. Même s'ils sont exactement les mêmes types de système de fichiers, par exemple NTFS, l'un peut utiliser le chiffrement ou la compression et l'autre non, ou les deux peuvent chiffrer les données, mais avec des clés différentes. Il n'est pas obligatoire que les données du fichier correspondent exactement à ce qui est stocké sur le disque, tout ce qui doit être stocké est une transformation réversible des données, afin que le système de fichiers puisse obtenir les données du fichier en faisant quelque chose avec les données sur le disque. Donc, à moins que les deux systèmes de fichiers n'utilisent exactement la même transformation, le simple échange de secteurs n'atteindrait pas l'objectif de transfert des données de fichier.

Pour toutes ces raisons, il est tout simplement trop de travail pour trop peu de gain pour les rédacteurs de système d'exploitation et les rédacteurs de système de fichiers d'implémenter une fonctionnalité qui optimise les déplacements sur les partitions pour les SSD. Ainsi, tout mouvement entre partitions sera une lecture et une écriture.

À l'intérieur du SSD, c'est une histoire légèrement différente. Bien que le système d'exploitation n'ait pas indiqué au lecteur qu'il copiait les données d'un endroit à un autre, les écritures sur les SSD sont si chères (et compliquées) que les contrôleurs SSD font beaucoup de travail pour minimiser les écritures. Certains disques SSD vont jusqu'à essayer de détecter lorsqu'un secteur en cours d'écriture sur le stockage correspond à un secteur déjà stocké et de marquer ce morceau de mémoire physique comme mappant maintenant sur 2 secteurs logiques différents plutôt que de le copier, en faisant au niveau du lecteur interne ce que le OS ne pouvait pas.

Mais ne comptez pas là-dessus.

Old Pro
la source
1
Votre dernier paragraphe n'implique-t-il pas que le système de fichiers doit être le même? Je suppose que le SSD ne sait pas quel système de fichiers fonctionne en haut. Si par exemple une partition utilise la compression et l'autre non, une copie par le SSD pourrait éventuellement corrompre le fichier.
blablabla
@blablabla Le dernier paragraphe supposait que les deux systèmes de fichiers stockent le contenu réel du fichier sur le disque sans altération. Je l'ai rendu explicite maintenant.
Ancien Pro