How does a HDD handle simultaneous writing?

[piknockyou]

Hello there!

I would please really need some qualified knowledge from you guys. (Not just guesses)

Example 1:
Let's say I run two separate copy processes for two large files A and B.
I copy both of them from my internal to my external hard drive simultaneously.
How are these sectors physically affected?
Is every byte of A and B written in turn on the same "line"?
So if I was playing file A, would the reading head always be skipping the inbetween bytes of B, thus making reading of A slower?

Example 2:
Let's say I download a file from the Internet, move a file from my USB-Stick and run an installation: All of them on the very same HDD.
How are these sectors physically affected?
Is every byte of every file written in turn on the same "line"?

Example 3:
I CUT several files from HDD 1 and MOVE them to HDD 2, so that HDD 1 gets free space by every moved file. At the very same time I do the same from HDD 2 to HDD 1.
How are the sectors of both HDD now physically affected?
I mean by every byte I move from HDD 1 space gets free for the bytes I move from HDD 2 to HDD 1.
What is happening there?
I there some kind of messed up, irregular, uneven mix of written bytes in an inappropriate order?

Are my assumptions in the 3 examples all wrong, since copying processes reserve the space they need first before they really begin?

Example 4:
I copy 100 GB of files on a brand new HDD.
Afterwards I permanently delete a file of 10 gb size, which is in the middle of the written sectors.
Next I copy a new 30 gb file on the HDD.
How are these sectors now physically affected?
Does the writing head now "fill out" the 10 gb "gap" first and copies the 20 gb left "behind" the former "100 gb line"?

Thanks a lot!
piknockyou

P.S.: Ihr könnt auch auf Deutsch antworten.
Dieser Post stammt von mir in diesem Forum:
http://forum.hddguru.com/viewtopic.php?f=1&t=30713&p=0&e=0&sid=e409ba033694064c9fa088e1e02f7ffc
Ich habe nie eine gute Antwort erhalten.

 

[Sannyboy111985]

Wichtig ist hierbei zu wissen, dass das ganze nicht die "Festplatte" in erster Instanz entscheidet, sondern das Betriebsystem bzw. das Filesystem. Und bei dem Filesystem hängt es dann noch von verschiedenen Einstellungen bzw. der Fragmentierung etc ab.
Für Linux weiß ich, dass sich EXT3 und EXT4 anders verhalten. Dabei kann das System noch mit verschieden "Schedulern" oder Prioritäten das generelle verhalten Beeinflussen.
Auch die Positionder Daten auf der Festplatte spielt eine Rolle. Sowie die größe der einzelnen Dateien.
Die Festplatte hat dann noch NCQ und TCQ und kann die eingehenden IOs optimieren und ggf. ändert sich das Verhalten noch je nach Firmware/Modell/Hersteller etc.

Das heißt allgemein kann man die Frage nur sehr schlecht beantworten bzw. muss viele Annahmen über das Verhalten treffen.

 

[SpiII]

Pro Platter (Scheibe in der HDD) ein Schreib-/Lesekopf.
Daher kommt die Dateigrößentötung weil die einzelnen Bits einer Datei dorthin geschrieben werden, wo Platz ist.

Egal in welcher Kombination, sobald 2 Prozesse auf der HDD ausgeführt werden, verlangsamen diese sich.
Stell dir einfach ein Lagerhaus mit Regalen und mehrteiligen Bausätzen in mehreren Kartons vor und nur ein Mitarbeiter pro 100m Regal.

 

[Gohst]

Schlussendlich entscheided bei allen Punkten das Dateisystem.

Jedoch haben alle Dateisysteme die Aufgabe Dateien soweit wie möglich phisikalisch an möglichst zusammenhängende Blöcke zu kopieren.
Für HDDs ist das natürlich stark von Vorteil.

Wenn du jetzt zwei Dateien gleichzeitig kopierst, so gehe ich stark davon aus, dass die abwechelungsweise geschrieben und gelesen werden. Und zwar Block um Block. Das entscheidet z.T auch das Betriebssystem bzw. eben der FileExplorer welcher mit dem Dateisystem kommuniziert und zulets das Dateisystem und die Firmware der HDD.

Diese oben erwähnten "Blöcke" sind die wichtigste und gleichzeitig einzige Grösse die das Dateisystem kennt. Auch wenn Dateien kleiner als ein einzelner Block sein sollten.

Ich denke das "skippen" von Blöcken kostet nicht viel Zeit. Die Zeiten des Defragmentier-Wahns sind vorbei und Dateisysteme heute weit effizienter und schlauer.

Übrigens kann einer Festplatte meiner Meinung nach mehrere Blöcke simultan auslesen und in den Buffer speichern.

Bei Szenario 2 wird es ähnlich sein. Ob die Bits der Dateien phisisch nebeneinander, hintereinander oder abwechslungsweise liegen dürfte nicht so viel ausmachen.

Du müsstest einzelen Sektoren überwachen und visualisieren um die Wahrheit zu sehen.

Im Detail betrachtet sind Dateisysteme eine hoch komplexe Sache.

 

[Mega-Bryte]

mal zu Beispiel 1 geantwortet:

Wenn die Kopierten Daten wirklich einfach nur im Wechsel abgelegt würden, dann müßte sich der SchreibLesekopf ja nie bewegen und nur am Ender die Dateieinträge ins Listing schreiben. Die Schreibgeschwindigkeit müßte dabei eigentlich dem sequentiellen Schreiben beider Dateien entsprechen und der Fortschritt der/des Kopierprozesse/-s vergleichbar schnell von Statten gehen. Da es aber aller Erfahrung nach zu massiven Geschwindigkeitseinbußen kommt, wäre meine Einschätzung eine Vorabreservierung von Platz für A und dahinter für B und eine wie ja auch meist zu hörende sehr aktive Mechanik im wechselnden Zugriff auf die beiden Schreibbereiche. ähnlich "aktiv" düfrte aber auch die Mechanik im Leselaufwerk.

Ergänzung (13. Januar 2017)

Pro Platter (Scheibe in der HDD) ein Schreib-/Lesekopf.

Nanu, woher kommt denn diese Annahme? Wenn dann Pro Seite eines Platters. Dass der aber mit einem Kopf eines Nachbarplatters auf demselben Arm angebracht ist, interessiert nur dann wieder, Wenn auch auf dem Platter was passieren soll.

 

[Jörich]

I dont know much about the exact order of writing since hdd firmware and filetable stuff is a blackbox to me. But you can still look at the final results with this Microsoft Sysinternals Tool. It is like the Defrag window from old days, but you can zoom in and find out what the results are. You could test atleast some of your scenarios yourself. Good Question by the way! Very interesting.

Note: Nothing about Platters and Read/Write Heads.

 

[Holt]

Entscheidend ist dabei das Betriebssystem, dort einmal der Treiber für die HDD, vor allem ob der NCQ unterstützt (bei AHCI üblich, die HDD gibt aber an wie viele Befehle maximal parallel offen sein dürfen) und das Filesystem im OS (das ist ja mehr als nur dessen Datenstrukturen auf der Platte, es ist eine Menge Software), denn das entscheidet wo die Daten am Ende auf der Platte liegen. Dann wird in aller Regel beim Beispiel 1 abwechselnd ein Teil von beiden Dateien gelesen und kopiert, wenn NCQ aktiv ist, abliegt es auch der Platte was wann gelesen wird, aber generell wird es bei einer HDD sehr viel langsamer sein zwei Dateien zeitgleich lesen zu wollen, weil es immer zu Kopfbewegungen zwischen den Positionen der beiden Dateien auf der Platte kommt, denn es müssen beide Anfragen bedient werden, damit es nicht zu einem Timeout kommt.

Auch im Beispiel 2 entscheidet eben das OS wo die Daten liegen werden, nicht die Platte. Bei SSDs kann deren Controller entscheiden wo die Daten im NAND liegen, aber auch nicht unter welcher externen Adresse (LBA) diese abgelegt werden, darüber entscheidet alleine das OS, den das verwaltet das Filesystem und dort wird auch vermerkt welche Datei an welche Adresse steht.

Bei Beispiel 3 sollte man ebenfalls nicht vergessen, dass das Löschen von Dateien alleine das setzen eines Flags in den Verwaltungsdaten des Filesystems ist und dies eben entscheidet wo neue Dateien geschrieben werden, wenn wenig Platz frei ist, werden die neuen Daten sehr bald dort geschrieben wo vorher die Daten der eben gelöschten Datei standen, sonst wird z.B. Windows diese Adressen erst einmal nicht überschreiben, weshalb man oft eine Chance hat gelöschte Dateien wiederherzustellen. Wirklich überschrieben wird ja beim Löschen durch das Betriebssystem erst einmal nichts. Bei SSD mit TRIM siehst das anderes aus, da teil das Betriebssystem der SSD mit, welche Adressen die gelöschten Dateien belegt hatten und damit kann der Controller intern die NAND Adressen wo diese lagen dann freimachen. Die Antwort enthält auch die Antwort auf Beispiel 4, bei Windows wäre das sicher nicht der Fall, sofern die Partition deutlich größer als 120GB ist, denn NTFS hat immer einen für dem MFT reservierten Bereich (per Default ist der 12,5% groß) der erst wenn sonst kein Platz mehr frei ist, mit Nutzdaten belegt wird.

Festplatten verwalten selbst keine Partitionen, Dateien oder Verzeichnisse, die kennen sie gar nicht, die bekommen nur Befehle um einen Bereich von LBAs zu lesen oder zu schreiben, also ab LBA x dann die nachfolgenden y LBA zu übertragen. Ob das Nutzdaten sind, die Partitionstabelle oder ein Verzeichniseintrag des Filesystem ist ihnen nicht bekannt und auch total egal. Die Interpretation der Daten und die Erzeugung dieser Lese- und Schreibbefehle ist die Sache des Betriebssystems.

 

[Raucherdackel!]

Sehr interessant, ist dann Seagates Skyhawk Serie (ehemals Surveillance) dann nichts anderes als pures Marketing? Ich hab mir diese Frage doch desöfteren gestellt. Ich zitiere mal von deren Website:

SkyHawk™-Überwachungsfestplatten sind für DVR- und NVR-Geräte optimiert, auf Workloads im Dauerbetrieb ausgelegt und bieten Speicherkapazitäten bis 10 TB. SkyHawk verfügt über die erweiterte ImagePerfect™-Firmware zur Verringerung des Abfalls der Bildwiederholrate und von Ausfallzeiten bei einer dreimal so hohen Workload-Rate wie bei einer Desktop-Festplatte. Zudem ist die Festplatte in der Lage, in 90 % der Zeit aufzuzeichnen und unterstützt bis zu 64 HD-Kameras.

Wie funktioniert diese "erweiterte ImagePerfect™-Firmware"?

 

[Sannyboy111985]

Das musst du Seagate fragen müssen
Aber vermutlich wird die Firmware und ggf. auch die Hardware auf eine andere Workload ausgelegt sein.
Vermutlich wird hier der Cache anders verwendet, sprich hält daten länger im Cache anstatt sie schnell wegzuschreiben und liest ggf auch viel mehr Daten als angefordert.

 

[Holt]

Das ist einmal eine Auslegung vor allem auf Schreibzugriffe, die meisten Überwachungsvideos werden ja nie angesehen, außer wenn denn wirklich mal was passiert ist und dann ist es die Unterstützung der ATA Streaming Befehle, die auch nur bestimmte HDDs unterstützen. Dabei gibt jeder Befehle vor wie lange seine Ausführung dauern darf und wenn es eben einen Fehler gibt wird dann bei Verwendung dieser Befehle eben lieber mal ein Bit falsch wiedergegeben statt eines Lesefehler oder statt das die Platte versucht die Daten doch noch korrekt zu lesen, dafür dann aber das Video stockt. Die HW ist übrigens auch dafür ausgelegt, verträgt also Dauerbetrieb und auch einen größeren Workload, es ist also mehr als nur Marketing, wie oft unterstellt wird.

 

[Raucherdackel!]

Ok danke. Gut zu wissen dass ich mir doch kein Gelumpe gekauft hab