Verschieben einer Datei zwischen zwei Laufwerken auf einer SSD - wird sie kopiert?


18

Beim Verschieben einer Datei innerhalb eines Laufwerks wird die Datei nicht kopiert und gelöscht. Die Tabelle, die sich auf die Dateien bezieht, wird gerade aktualisiert. Und soweit ich weiß, ist das bei 2 Festplatten auf einer Festplatte nicht der Fall. SSDs unterscheiden sich jedoch, da für jedes Laufwerk kein physischer Speicherplatz reserviert ist. ( Quelle )

Meine Frage ist also, was passiert, wenn eine Datei von einem Laufwerk auf ein anderes auf derselben SSD verschoben wird, die Bytes kopiert und das Original gelöscht werden oder eine Tabelle aktualisiert wird, wodurch die SSD weniger überlastet wird?

Es gibt bereits eine doppelte Frage hier . Aber beide Antworten behaupten:

Jede Partition hat einen eigenen physischen Bereich des Laufwerks für sich

und

Durch das Partitionieren einer Festplatte werden tatsächlich physische Regionen für jede Partition festgelegt. [und in einem Kommentar:] SSD ist immer noch eine Festplatte, es hat nur keine Festplatte.

Soweit ich weiß, ist das falsch. Sehen Sie hier .

Kann mir jemand, der mehr über SSDs weiß, mitteilen, ob seine Einschätzung trotz des Fehlers korrekt ist?


14
Die dort akzeptierte Antwort ist richtig: Jede Partition hat ein eigenes, unabhängiges Dateisystem. Jedes Dateisystem entscheidet für sich, wie es die ihm zugewiesenen Blöcke verwendet. Um das zu tun, was Sie für die Firmware von SSD vorschlagen, mvmüssten Dateisysteme und Userland-Tools wie Linux zusammenarbeiten und Abstraktionsschichten stark mischen.
Kamil Maciorowski

2
@Kamil: Wenn das Betriebssystem es implementieren würde, mvmüsste es tatsächlich weniger tun als derzeit, vermute ich. (Das heißt, das Betriebssystem muss nur sicherstellen, dass ein dateisystemübergreifendes Umbenennen () erfolgreich ist, anstatt wie derzeit zu scheitern.)
grawity

16
"2 Laufwerke auf [einer SSD / HDD]" - Ich denke, Sie meinen 2 Dateisysteme oder 2 Partitionen auf einer SSD / HDD. Denken Sie daran, dass das letzte "D" in beiden Akronymen "Laufwerk" ist. Sie sagen also 2 Laufwerke in einem Laufwerk, was keinen Sinn ergibt.
JoL

1
Nehmen Sie zum Beispiel das Dialogfeld "Datenträgerverwaltung". Es heißt, Change Drive Letter and Pathswenn auf eine Partition / ein Volume verwiesen wird.
ispiro

4
@ispiro Ist das unter Windows? Scheint eine schreckliche Art, Benutzer zu verwirren. Ich kann nur vermuten, dass sie den Begriff "Laufwerksbuchstabe" vor der Implementierung von Laufwerkspartitionen erfunden haben und dann Laufwerkspartitionen als eigenständige "Laufwerke" dargestellt haben. Jetzt können Sie mehrere Windows-Laufwerke haben, die Partitionen eines Hardwarelaufwerks darstellen ...
JoL

Antworten:


38

Soweit ich weiß, ist das falsch

Die zitierte Beschreibung ist halb richtig, halb falsch. Aber es ist auch halb falsch für Festplatten.

Durch Partitionieren eines Laufwerks werden logische Bereiche für jede Partition festgelegt. Das Betriebssystem kümmert sich überhaupt nicht um physische Speicherorte - es fordert das Laufwerk lediglich auf, "den logischen Block # 31415926 zu lesen ", und das Laufwerk entscheidet selbst, wo sich die Daten befinden. Dies funktioniert genauso für Magnet- und Flash-Speicher.

Eigentlich ist es dasselbe wie bei Festplatten der letzten 20 bis 25 Jahre: Obwohl in früheren Betriebssystemen physische Speicherorte für Zylinder / Kopf / Sektor verwendet wurden, ist dies längst vorbei. Sie wissen nicht genau, wo auf welcher Platte LBA # 1234 aufbewahrt wird. Festplatten ordnen sogar fehlerhafte physische Sektoren automatisch neu zu, sodass derselbe LBA plötzlich aus einem völlig anderen physischen Bereich gelesen werden kann - genau wie bei SSDs.

Sowohl bei Festplatten als auch bei SSDs verfügt das Betriebssystem lediglich über eine Reihe von LBAs (z. B. 0–999999), von denen Daten gelesen und geschrieben werden können. Der Zweck der Partitionierung besteht darin, Unterbereiche darin zuzuweisen - z. B. Partition A erhält 10–499999, Partition B erhält 500000–999999. Jede Partition hat ein unabhängiges Dateisystem, und Dateisysteme in jeder Partition können nicht auf Daten außerhalb verweisen - sie können die Partitionsgrenzen nicht überschreiten. (Partition A kann beispielsweise keine Datei enthalten, deren Daten im Sektor 600000 gespeichert sind.)

Infolgedessen müssen alle Dateien, die von einer zur anderen verschoben werden, vollständig kopiert werden.

(Das heißt, in der Theorie das OS in der Lage sein zu fragen , die Platte selbst Daten von einem Bereich zum anderen zu kopieren (zB „kopieren LBA # 1234 bis # 567890“), ohne dass es auf den Hauptspeicher kopieren zu müssen und dann zurück und dies würde natürlich die Partitionsgrenzen vollständig umgehen. Dies könnte zum Beispiel die "Flash-Übersetzungsschicht" der SSD nutzen. Aber in der Praxis wird dies, soweit ich weiß, nicht gemacht.)


Ich nehme an, du hast recht. Beachten Sie jedoch, dass es eine andere Option gibt. Das Laufwerk könnte entscheiden, dass Sektor # 001 auf Laufwerk # 1 jetzt mit Sektor # 123 in Laufwerk # 2 wechselt (dh Sektor # 001 auf Laufwerk # 1 bezieht sich jetzt auf die physischen Daten, die früher als Sektor # 123 in bezeichnet wurden Laufwerk 2), wodurch die Datei verschoben wird , ohne dass die Bytes kopiert werden müssen. Das Verschieben einer TB an Daten kann also im Prinzip nahezu augenblicklich erfolgen.
Ispiro

15
Das Laufwerk kennt keine Dateien oder Dateisysteme und kann solche Entscheidungen daher nicht selbst treffen. Es muss eine Anforderung vom Betriebssystem erhalten, damit dies geschieht. Wie ich bereits im letzten Absatz erwähnt habe, ist dies sicherlich technisch möglich, aber Betriebssysteme kümmern sich normalerweise nicht darum, ob es sich um dateisystemübergreifende Kopien handelt, und ich bezweifle, dass dies auch für dateisystemübergreifende Kopien der Fall ist (häufiger auf FS-Ebene).
Grawity

6
Bestimmte SSDs implementieren die Deduplizierung auf Blockebene. Sandforce ( en.wikipedia.org/wiki/SandForce#Technology ) war einer der ersten, der dies implementierte, und seine Controller fanden Eingang in die Produkte mehrerer SSD-Hersteller. Sandforce-Controller hatten einen "Schreibverstärkungsfaktor" von weniger als eins - was bedeutet, dass sie weniger Daten in den Flash-Speicher geschrieben haben, als das Betriebssystem an das Laufwerk gesendet hat. Zum Vergleich: SSDs haben im Allgemeinen einen Schreibverstärkungsfaktor von mehr als eins.
Hojusaram

2
@hojusaram: Stimmt, aber es ist immer noch eine post-factum-Deduplizierung - weniger Flash-Schreibvorgänge, aber die Daten werden weiterhin gelesen, von der Festplatte in den Betriebssystemspeicher und dann zurück auf den Festplattencontroller kopiert. Was ispiro meinte, ist meiner Meinung nach das SSD-Äquivalent von "reflink" oder "copy on write" (z. B. cp --reflink), das das Betriebssystem explizit von der Festplatte verlangen könnte, selbstständig zu arbeiten.
Grawity

1
Es wäre interessant zu erfahren, wie APFS damit umgeht, da die Partitionsgrenzen nicht mehr festgelegt sind und ohne Eingreifen des Benutzers geändert werden können.
Tetsujin

9

Was passiert, wenn Daten auf eine Solid State Disk geschrieben werden, verdient mehrere Artikel (gute Zusammenfassung hier ), da es sehr kompliziert ist und von der zugrunde liegenden Technologie abhängt. Die kurze Geschichte ist, dass SSDs im Allgemeinen keine Null-Bits in den Speicher schreiben können. Stattdessen müssen sie einen ganzen Abschnitt des Speichers auf Null setzen (löschen), und anschließend können sie Daten speichern, indem sie nur die Einsen darauf schreiben. Typischerweise schreiben sie heutzutage Blöcke von 512 Bytes, löschen aber eine Seite von 8 Blöcken, was 4096 ist. Dies und die Tatsache, dass jeder Schreib- / Löschzyklus eine gewisse physische Abnutzung des Speichers verursacht und der Speicher schließlich abnutzt, machen SSDs sehr unterschiedlich als sich drehende magnetische Festplatten.

Abgesehen davon implementieren SATA-Laufwerke (und AFAIK SAS-Laufwerke) keinen nativen Befehl zum Kopieren von Daten von einem Sektor in einen anderen. (Zumindest nichts in der SATA- oder SAS-Spezifikation erfordert dies, sodass das Betriebssystem nicht damit rechnen kann, dass ein solcher Befehl verfügbar ist.) Bei einer Dateikopie über eine Partition werden also die Daten von einem Laufwerkssektor in den Hostspeicher gelesen und anschließend geschrieben es wieder auf die Fahrt in einem anderen Sektor.

Dies liegt daran, dass für das Betriebssystem ein Laufwerk aus einer Reihe von nummerierten logischen Sektoren besteht und nur aus Sektoren gelesen und in Sektoren geschrieben werden kann. Das Betriebssystem kann das Laufwerk nicht anweisen, Sektoren neu zuzuordnen.

Darüber hinaus besteht das Dateisystem (HFS +, NTFS, ext3 usw.) aus einer Reihe von Datenstrukturen, die einer Reihe von logischen Blöcken eine Reihenfolge auferlegen. Diese Datenstrukturen implementieren "Dateien", "Dateinamen", "Verzeichnisse", "Berechtigungen" usw. Wenn Sie also eine Datei von einem Verzeichnis in ein anderes verschieben, wird sie nicht kopiert. Nur die Dateisystemdaten, die angeben, in welchem ​​Verzeichnis sich die Datei befindet, werden aktualisiert.

Das Konzept einer Partition besteht darin, dass es sich um eine Gruppe logischer Sektoren auf dem Laufwerk handelt, die von einem einzelnen Dateisystem beansprucht werden. Dies hat zur Folge, dass ein Dateisystem möglicherweise nicht auf Sektoren außerhalb seiner Partition zugreift. Dies ist größtenteils eine Sicherheitsfunktion, beruht jedoch auch auf der Tatsache, dass die Datenstrukturen des Dateisystems so aufgebaut sind, dass jeder Sektor des Laufwerks im Besitz des Dateisystems ist, und dass das Hinzufügen oder Entfernen von Sektoren nicht trivial ist zu diesen Strukturen. Aus diesem Grund müssen Sie spezielle Routinen ausführen, um die Größe einer Partition anzupassen, und auch, warum Dateisysteme darauf bestehen, auf einer zusammenhängenden Gruppe von Sektoren ausgeführt zu werden.

Daher ist es unpraktisch und gefährlich, eine Dateikopie so zu implementieren, dass nur Sektoren von einem Dateisystem in ein anderes übertragen werden. Auf einem sich drehenden Magnetlaufwerk wäre dies auch ein Albtraum für die Leistung, da das Laufwerk zwar Ausnahmen für fehlerhafte Sektoren macht, die Sektoren jedoch physisch so angeordnet sind, dass die Lese- und Schreibgeschwindigkeit von fortlaufend nummerierten Sektoren optimiert wird Branchen.

Darüber hinaus können in 2 Dateisystemen Dateidaten möglicherweise nicht auf dieselbe Weise auf der Festplatte gespeichert werden, sodass das Austauschen von Sektoren auch dann nicht funktioniert, wenn dies praktisch wäre. Selbst wenn es sich genau um dieselben Dateisystemtypen handelt, beispielsweise NTFS, verwendet einer möglicherweise Verschlüsselung oder Komprimierung und der andere nicht, oder beide verschlüsseln möglicherweise die Daten, jedoch mit unterschiedlichen Schlüsseln. Es ist nicht erforderlich, dass die Daten in der Datei genau das sind, was auf der Festplatte gespeichert ist. Alles, was gespeichert werden muss, ist eine umkehrbare Transformation der Daten, sodass das Dateisystem die Daten der Datei abrufen kann, indem es etwas damit macht die Daten auf der Festplatte. Wenn also nicht beide Dateisysteme genau die gleiche Transformation verwenden, kann durch einfaches Austauschen von Sektoren das Ziel der Übertragung der Dateidaten nicht erreicht werden.

Aus all diesen Gründen ist es für die Betriebssystem- und Dateisystemschreiber zu viel Arbeit und zu wenig Gewinn, eine Funktion zu implementieren, die das Verschieben zwischen Partitionen für SSDs optimiert. Jede partitionsübergreifende Verschiebung ist also ein Lesen und ein Schreiben.

Bei der SSD ist das eine etwas andere Geschichte. Obwohl das Betriebssystem dem Laufwerk nicht mitteilte, dass Daten von einem Ort zum anderen kopiert werden, sind Schreibvorgänge auf SSDs so teuer (und kompliziert), dass SSD-Controller viel Arbeit leisten, um Schreibvorgänge zu minimieren. Einige SSDs versuchen zu erkennen, wann ein Sektor, der in den Speicher geschrieben wird, mit einem bereits gespeicherten Sektor übereinstimmt, und markieren diesen physischen Teil des Speichers so, dass er nun zwei verschiedenen logischen Sektoren zugeordnet ist, anstatt ihn zu kopieren Betriebssystem konnte nicht.

Aber rechnen Sie nicht damit.


1
Bedeutet Ihr letzter Absatz nicht, dass das Dateisystem dasselbe sein muss? Ich würde annehmen, dass die SSD nicht weiß, welches Dateisystem oben läuft. Wenn zum Beispiel eine Partition die Komprimierung verwendet und die andere nicht, würde eine Kopie der SSD möglicherweise die Datei beschädigen.
Blablabla

@blablabla Der letzte Absatz ging davon aus, dass beide Dateisysteme den tatsächlichen Dateiinhalt unverändert auf der Festplatte speichern. Ich habe das jetzt explizit gemacht.
Old Pro
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.