Archiv verlassen und diese Seite im Standarddesign anzeigen : Warum ist die Datenübertragungsrate bei vielen kleinen Dateien gering [HDD]
Trunk
2015-12-21, 13:42:13
Hallo,
Mich würde es mal interessieren, warum die Datenübertragungsrate beim kopieren vieler kleiner Dateien so signifikant geringer ist, als wenn eine große Datei kopiert wird?
Angenommen ich kopiere eine ISO á 4GB und 1024 MP3s á 4MB von einer HDD auf eine andere HDD.
Erfahrungsgemäß kopiert die ISO mit 80-100MB/s, die MP3s mit 5-25MB/s. Woran liegt es? Cache? Fly-Time des Lese/Schreibkopfes? Dateisystem? Treiber? Wortbreite vom BUS? Fragmentierung?
Bei kleinen Dateien sind die Zugriffszeiten der HDD nicht mehr vernachlässigbar, pro Datei muss auf Verzeichnisstruktur und Datei selbst zugegriffen werden, die Seek time (https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics) (z.B.9ms) kommt also mehrmals pro Datei zum tragen.
Trunk
2015-12-21, 14:31:47
Ah, die "Fly-Time" heißt also Seek Time :D
Verstehe ich es richtig, dass die Seek Time weniger wäre, wenn die Verzeichnisstruktur aus einem Cache kommen würde?
Verzeichnisstruktur = Index welche Datei aus welchen Sektoren besteht?
Angenommen, die MP3s liegen alle hintereinander in den Sektoren der Platte. Die ISO-Datei von Sektor 0-8.555.712, MP3s Sektor 10.000.000-18.555.712
Normalerweise liest die Platte die Verzeichnisstuktur, kopiert die Sektoren für eine Datei, liest wieder die Verzeichnisstruktur, kopiert wieder Sektoren...
Wäre es nicht schlauer, der Platte zu sagen "Diese Dateien will ich alle Lesen", die HDD liest Verzeichnisstruktur und lockt den Bereich (sektoren) für diese Dateien?
Oder, selbst wenn noch kleine Dateien zwischen den Sektoren liegen, könnte man nicht einfach alle Sektoren sequentiell lesen und später die Verzeichnisstruktur abgleichen?
Und wie kommt es, dass der Effekt auch bei SSDs und FLASH auftritt?
Ah, die "Fly-Time" heißt also Seek Time :D
Verstehe ich es richtig, dass die Seek Time weniger wäre, wenn die Verzeichnisstruktur aus einem Cache kommen würde?
Verzeichnisstruktur = Index welche Datei aus welchen Sektoren besteht?
ja
Angenommen, die MP3s liegen alle hintereinander in den Sektoren der Platte. Die ISO-Datei von Sektor 0-8.555.712, MP3s Sektor 10.000.000-18.555.712
Normalerweise liest die Platte die Verzeichnisstuktur, kopiert die Sektoren für eine Datei, liest wieder die Verzeichnisstruktur, kopiert wieder Sektoren...
Wäre es nicht schlauer, der Platte zu sagen "Diese Dateien will ich alle Lesen", die HDD liest Verzeichnisstruktur und lockt den Bereich (sektoren) für diese Dateien?
In einem multithreaded System ist dies nur schlecht möglich, es können ja hunderte von Threads gleichzeitig auf die Platte zugreifen(Beim Booten ist dies z.B. der Fall)
Oder, selbst wenn noch kleine Dateien zwischen den Sektoren liegen, könnte man nicht einfach alle Sektoren sequentiell lesen und später die Verzeichnisstruktur abgleichen?
das gibt es, nennt sich read-ahead caching
Und wie kommt es, dass der Effekt auch bei SSDs und FLASH auftritt?
Auch bei SSDs gibt es eine Zugriffszeit, nur ist diese um 10er Potenzen kleiner
Gruss
Trunk
2015-12-21, 15:08:20
Mag ja sein, dass eventuell auch andere Threads auf die selbe Datei / auf den selben Sektor zugreifen wollen.
Nur wann ist das auf meinem Windows Desktopsystem der fall? Beim Booten kann das OS es ja gern verbieten. Auch generell kann die HDD doch, ähnlich wie File-Locks, sektor-locks verwenden, damit daten nicht korrupt werden.
Wenn beim Kopiervorgang der MP3s auf einmal ein anderer Prozess jede MP3 einliest, ist klar dass die Datenrate einbricht. Aber wenn nur je 1 MP3 abgespielt wird während des kopierens, wird die Datei ja eher 1x eingelesen und die HDD könnte weiter alle anderen Daten lesen. Und schreiben sollte auch kein Problem sein, wenn noch genügend freier Speicher existiert.
Bin ich der einzige, der findet, HDDs bzw. Speicher generell müsste mal etwas "smarter" werden? Kann doch nicht sein, dass in 2015 Windows immer noch meine Musik mit 20MB/s kopiert, während Spieldaten 4-5x so schnell übertragen werden können?
Nicht die HDD, sondern das Betriebssystem bzw. Filesystem sollten smarter werden, das würde für den Enduser fast kostenneutral gehen, aber da ist wahrscheinlich nichts mehr zu erwarten...
Was ich mache wenn ich viele kleine Dateien auf ein langsames Zielmedium kopieren muss: Zippen mit geringer oder ohne Kompression, dann hat man wieder eine große Datei und hohe Performance. Ansonsten hilft nur viel RAM (->Cache).
OBrian
2015-12-25, 23:57:02
Da SSDs nicht nur im Kommen sind, sondern sich anschicken, alle Anwendungsgebiete normaler Festplatten nach und nach komplett aufzurollen, wird bei mechanischen Platten auch gar nichts mehr passieren. Selbst auf Kapazitätsvergrößerungen muß man ja inzwischen ewig warten, bei einer halben Handvoll TB ist Schicht im Schacht. SSDs sind schon bei 1 TB für 200 €, ein kleiner Abstand ist also noch da, aber das Ende ist nahe für die mechanischen.
Also wenn überhaupt, dann Baustelle Dateisystem. Aber auch da wird man sich auf SSDs konzentrieren, wenn was gemacht wird. Und SSDs sind erstens sowieso schneller und zweitens wächst deren Performance auch noch drastisch (z.B. die NVMe-Varianten sind schon wieder ein Mehrfaches schneller als die 2,5"-SATA), so daß kein Bedarf besteht, irgendwelche Experimente bzgl. Dateisystem zu starten.
myMind
2015-12-26, 00:09:12
Selbst auf Kapazitätsvergrößerungen muß man ja inzwischen ewig warten, bei einer halben Handvoll TB ist Schicht im Schacht.
Klassische HDDs sind gerade beim Sprung von 8TB auf 10TB (HGST Ultrastar Archive Ha10 10TB).
del_4901
2015-12-26, 00:46:01
Smarter/optimierter code ist meistens komplexer und schlechter wartbar. Das will man beim File System eigentlich nicht haben. Und da noch was für die alten HDDs zu machen während keine gute Investition mehr.
Rooter
2015-12-26, 01:34:10
Klassische HDDs sind gerade beim Sprung von 8TB auf 10TB (HGST Ultrastar Archive Ha10 10TB).Ja, als Archive-HDD, mit lustigen Ideen wie Edelgasfüllung und sich überlappenden Spuren. :rolleyes:
Mit heat assisted magnetic recording geht's ja auch nicht voran, wobei ich das auch schon wieder viel zu Komplex finde (Stichwort Langlebigkeit)
MfG
Rooter
drdope
2015-12-26, 06:38:26
Smarter/optimierter code ist meistens komplexer und schlechter wartbar. Das will man beim File System eigentlich nicht haben. Und da noch was für die alten HDDs zu machen während keine gute Investition mehr.
Geht man derzeit nicht genau diesen Weg, um in größeren Storage-Umgebungen die Nachteile von SMR-HDDs (http://events.linuxfoundation.org/sites/events/files/slides/SMR%20in%20Linux%20Systems%20-%20Vault.pdf) zu kompensieren (Stichwort Host -Managed vs Drive-Managed)?
Iirc liefert deshalb HGST seine SMR Platten nicht an Consumer aus, sondern nur an größere OEMs die die komplette Kontrolle über HDDs, eingesetzte Controller und das darüber liegende Software-Stack haben.
myMind
2015-12-26, 09:34:21
Ja, als Archive-HDD, mit lustigen Ideen wie Edelgasfüllung und sich überlappenden Spuren. :rolleyes:
8TB gibt es auch als normale Desktop oder NAS/Enterprise Disks.
del_4901
2015-12-26, 11:47:55
Geht man derzeit nicht genau diesen Weg, um in größeren Storage-Umgebungen die Nachteile von SMR-HDDs (http://events.linuxfoundation.org/sites/events/files/slides/SMR%20in%20Linux%20Systems%20-%20Vault.pdf) zu kompensieren (Stichwort Host -Managed vs Drive-Managed)?
Iirc liefert deshalb HGST seine SMR Platten nicht an Consumer aus, sondern nur an größere OEMs die die komplette Kontrolle über HDDs, eingesetzte Controller und das darüber liegende Software-Stack haben.Das verschiebt doch nur Komplexität von der Firmware in das OS. Mehr wird es dadurch nicht. Evtl. Wird das Sytem dadurch sogar einfacher.
Achill
2015-12-26, 12:05:30
Ich denke das die HDD Technik schon sehr ausgereift ist - Weiterentwicklung wird damit immer Kostspieliger.
Das erste "Teilchen" war von IBM im Jahre 1956 - „IBM 350“ - mit einer Kapazität von 5 MB, 24 Zoll, 600 ms Zugriffszeit, 1.200 rpm, 500 kg, 10 kW (siehe Wiki (https://de.wikipedia.org/wiki/Festplattenlaufwerk#Geschichte)).
Da das grundlegende Prinzip bei HDD gleich geblieben ist (mechanische Funktionsweise), fußen die Verbesserung der Leistung in den verschiedenen Bereichen (imho) maßgeblich auf der Minituarisierung der Technik und werden durch physikalischen Grenzen limitiert.
Die Betriebssysteme arbeiten auch schon sehr effizient mit HDDs, Linux hat z.B. verschiedene File-Scheduler, die auf Kosten von etwas mehr Latenz, ein Query-Buffer aufbauen um dann eine möglichst optimale R/W-Sequenz zu finden. Das spielt sich aber alles im Millisekunden-Bereich ab und kann vom User noch getuned werden.
myMind
2015-12-26, 22:05:11
Vielleicht ist es sinnvoll sich dazu die einmal anzuschauen, wie die I/O-Verarbeitung unter Windows funktioniert. Im Groben:
https://storagegaga.files.wordpress.com/2012/01/snia-data-path-stack.jpg
Quelle: https://storagegaga.wordpress.com/tag/hdd/
So weit so übersichtlich. Wie das Ganze dann aber im Detail funktioniert, kann man z.B. auf der Seite "Understanding the Windows I/O System (https://www.microsoftpressstore.com/articles/article.aspx?p=2201309)" aus den "Windows Internals" nachlesen. Muss man nicht wirklich machen, aber beim Querlesen des Artikels wird schnell deutlich, dass die Dinge kompliziert sind. Gerade beim Starten und Beenden einer I/O-Operation passiert schon so einiges.
Nach meinem Verständnis ist die Antwort zu diesem Thread genau die gleiche wie auf die Frage, warum man für einen Wocheneinkauf insgesamt weniger Zeit benötigt, als wenn man jeden Tag einkaufen ginge. Selbst wenn man die Zeit im Markt (Kopierzeit) als gleich annimmt, hat man immer noch Zusatzaufwand für mehr Hin- und Rückfahrten (Datei öffnen und schließen).
qiller
2016-01-04, 22:55:40
Hallo,
Mich würde es mal interessieren, warum die Datenübertragungsrate beim kopieren vieler kleiner Dateien so signifikant geringer ist, als wenn eine große Datei kopiert wird?
Angenommen ich kopiere eine ISO á 4GB und 1024 MP3s á 4MB von einer HDD auf eine andere HDD.
Erfahrungsgemäß kopiert die ISO mit 80-100MB/s, die MP3s mit 5-25MB/s. Woran liegt es? Cache? Fly-Time des Lese/Schreibkopfes? Dateisystem? Treiber? Wortbreite vom BUS? Fragmentierung?
Also ich habs eben mal getestet.
6GB an MP3s von ner SSD auf eine HDD geschrieben: Leserate der SSD 300+MB/s, Schreibrate der HDD 55-80MB/s, auf eine andere HDD warens sogar 85-95MB/s.
MP3s sind viel zu groß um da ne deutliche Diskrepanz zu zeigen. Und wenn deine Platte nur 5MB/s schafft, dann lüppt da eindeutig was falsch.
Wenn ich jetzt 6GB an kleinen Word-Dateien hätte, würde die Datenübertragungsrate schon ganz anders aussehen.
Und um die Frage des TE zu beantworten: Maßgeblich ist die hohe Zugriffszeit von HDDs für die geringe Datenübertragungsrate verantwortlich. Und mit Techniken wie Caching, Defragmentierung/Neuanordnung, Pre-/Superfetch, AHCI/NCQ etc. versucht man auf verschiedenen Ebenen genau diesen Umstand abzumildern.
MP3s sind viel zu groß um da ne deutliche Diskrepanz zu zeigen. Und wenn deine Platte nur 5MB/s schafft, dann lüppt da eindeutig was falsch.
Wenn ich jetzt 6GB an kleinen Word-Dateien hätte, würde die Datenübertragungsrate schon ganz anders aussehen.
Nimm mal ein paar Eclipse IDEs mit etwas gefüllten Workspaces. ;) Da hast Du genug kleine Funzeldateien.
qiller
2016-01-04, 23:04:32
Ja, oder sowas. Wollte auch nur sagen, dass die Einbrüche in der Datenrate bei 3-10MB großen Dateien normalerweise noch eher gemächlich sind.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.