Hi!
Das ist eine recht komplexe Sache. Versuchen wir es mal mir meinem Wissen zu betrachten (das ist allerdings auch nicht mehr 100% auf der Höhe der Zeit).
Ich bin mir mir ziemlich sicher, dass LESEN nicht das Problem ist, sondern SCHREIBEN. Warum, dazu kommen wir später.
Dann bin ich mir nicht sicher, ob beim Lesen große Dateien generell schneller geladen werden, als kleine. Das liegt einfach daran, dass bei einem Lesezugriff mindestens drei Leseoperationen laufen müssen:
1. Wir müssen die Datei im Verzeichnis finden
Über diesen Verzeichniseintrag finden wir dann auch die Stelle, wo der Dateiinhalt abgelegt ist.
2. Wir müssen den eigentlichen Dateiinhalt laden
Der liegt auf dem Datenträger, aber nicht direkt "neben" dem Verzeichniseintrag.
3. Eine Liste der von einer Datei belegten Sektoren muss geladen werden
Die Sektoren einer Datei liegen nicht hintereinander, deshalb kennen moderne Dateisysteme Verwaltungssektoren, welche die Reihenfolge der belegten Sektoren einer Datei enthalten.
Je größer die Datei ist, desto häufiger müssen diese Verwaltungssektoren gelesen werden.
Kleinere Dateien laden natürlich weniger dieser Verwaltungssektoren, dafür muss dann bei vielen kleinen Dateioen häufiger der Dateieintrag gesucht werden.
Was da jetzt schneller ist? Keine Ahnung. OK, man kann es nicht nur an diese ganz einfachen Dingen festmachen. Da kommen dann immer noch lese-Optimierung des Dateisystems und des Datenträgers hinzu, die im Hintergrund arbeiten (Stichwort Lese-Cache). Da wirken dann solche Dinge wie Imvoraus-Lesen mit. Das wird oft was bringen, kann dann aber in ungünstigen Fällen auch bewirken, das der Cache verworfen wird und neu geladen werden muss. Ich tippe, das wird bei vielen kleinen Dateien häufiger vorkommen, als bei wenigen Großen.
Beim SCHREIBEN kommt nur noch weitere Komplexität hinzu: erst lesen wir die ganzen Informationssektoren udn verzeichniss udn dann schreiben wir neue Information dort hinein. Beim Schreiben der Daten werden die alten Daten erst nach dem schreiben der neuen Daten i wieder freigegeben.
Aber das reicht noch nicht an zusätzlichen Aufwand: soweit ich weiß sind die physikalisch geschriebenen Einheiten (Cluster) häufig größer als ein Sektor. Je mehr Sektoren in einem Cluster liegen, desto mehr Schreiboperationen, kann man mit passenden Schreibcache einsparen - wenn das denn alles passt.
Das Problem ist, dass dies bei kleinen Dateien vermutlich nicht immer gut passen wird. Spätestens, wenn eine neue kleine Datei geschrieben wird, die in einen Cluster soll, der bereits kurz vorher geschrieben werden sollte und jetzt gerade gesperrt ist, bis der alte Inhalt geschrieben wird, muss das ganze Warten.
Bei modernen Festplatten, hab ich gehört, dass teilweise die Spuren komplett geschrieben werden müssen, weil die Information auf der Spur so eng liegt, dass man nicht mehr sauber dazwischen einfügen kann. Die nächste Steigerung sind dann Spuren, die so schmal sind, dass man sie nicht sauber trennen kann. Auch soetwas hat man technisch im Griff und nutzt das.
https://www.storage-insider.de/was-ist-shingled-magnetic-recording-smr-a-856848/
Das sollte natürlich bei SSDs nicht zutreffen, da man dort ja bekanntermaßen ohne rotierende Speicherchips auskommen muss. 
Aber SSDs sind beim Speichern auch keine Zauberer. Da müssen komplexere elektronische Vorgänge ablaufen, die Zeit brauchen.
https://www.computerweekly.com/de/feature/Grundlagen-Wie-Flash-Speicher-funktioniert
"Die Eigenschaften von NAND-Flash sind so beschaffen, dass ein einzelner Wert in einer Zelle von 1 zu 0 geändert werden kann. Das funktioniert allerdings nicht umgekehrt, ohne den gesamten Block neu formatieren zu müssen. Dieser Vorgang ist als P/E-Zyklus (Program-Erase Cycle) bekannt."
Soweit, so alt ist mein technisches Grundwissen auf dem Gebiet.
Frag mich jetzt bitte nicht nach weiteren Details. Auf dem Gebiet bin ich soweit, wie unser bekannter Kollege der sich hier schon seit Jahren mit der Sinnfrage beschäftigt, wie das mit den Nullen und Einsen in der CPU funktioniert.
Ich hoffe, dass Mitleser die verbliebenen Lücken füllen können (auch wenn sie dabei alles für Lötsinn erklären müssen, weil es eben altes Wissen war und dann noch einmal bei Bienchen und Bytes neu anfangen müssen)
Bis dann
Andreas
Andreas42
Sovebämse
