Wieviele Bytes werden unter der Haube bei C & C++ Funktionen wirklich von der HD beim Zeilenweise lesen gelesen?

[Unter der Haube]

Mal angenommen man möchte eine Textdatei Zeilenweise einlesen,
was passiert dann im Hintergrund bei den entsprechenden C oder C++ Funktionen?

Eine Festplatte oder auch eine SSD ist ja ein Blockorientiertes Gerät, ich würde daher mal annehmen, dass Daten Blockweise eingelesen und dann in der C oder C++ Funktion in einer Art Zwischenspeicher oder Cache zwischengespeichert werden, aus der sie dann Zeilenweise ausgelesen werden können.

Ist dies so richtig, oder ist es wirklich so, dass diese Funktionen dann die Daten wirklich nur Zeilenweise anfordern, also bei z.B. einer Zeilenlänge von 80 Zeichen wirklich nur 80 Bytes einlesen?
Letzteres würde mir unsinnig vorkommen, aber ich frage sicherheitshalber mal, weil ich es gerne ganz genau wissen würde.
Denn wenn das so ist, dann lese ich in Zukunft die Daten lieber Binär und Blockweise ein, so dass es auf SSDs und HDs optimiert ist, speichere das gelesene zwischen und hole mir dann daraus meine Zeilen.

[Nathan]

Es gibt da schon diverse Buffer zwischen Stream und Festplatte.
Die streambuffer haben einen eigenen den sie bei Bedarf füllen und das OS auch noch mal einen, der bei Bedarf gefüllt wird.

[SeppJ]

Nathan schrieb:

Es gibt da schon diverse Buffer zwischen Stream und Festplatte.
Die streambuffer haben einen eigenen den sie bei Bedarf füllen und das OS auch noch mal einen, der bei Bedarf gefüllt wird.

Und die Festplatte selber hat in der Regel auch noch einen.

[hustbaer]

@Unter der Haube
Man kann die Daten vom OS üblicherweise Byteweise anfordern. Wobei das die meisten C++ Funktionen nicht tun. Andrerseits werden die meisten C++ Funktionen auch nicht darauf achten dass ihre Zugriffe immer genau an einer Sektorgrenze starten und enden. ^*

Das OS fordert die Daten von der HDD dann natürlich sektorweise an, bzw. muss auch sektorweise schreiben. D.h. wenn du ein einzelnes Byte in eine Datei reinschreibst, dann muss das OS erstmal den ganzen Sektor lesen, dann das eine Byte ersetzen, und dann den ganzen Sektor wieder zurückschreiben.

Wobei es innerhalb des OS üblicherweise auch noch eine Aufteilung gibt. Die read/write Funktionen des OS werden die Requests üblicherweise erstmal ziemlich 1:1 an den File-System-Treiber weiterleiten. Der File-System-Treiber kümmert sich dann z.B. darum Requests auf File/Byte Ebene in Requests auf Volume/Sektor Ebene zu verwandeln. Diese Requests schickt er dann dem Volume-Treiber, welcher daraus dann Device/Sektor Requests macht die er wiederrum dem Treiber des Mass-Storage Device (=z.B. dem SATA Controller) schickt. Und der schickt sie dann an das Device.
Und irgendwo ist dabei noch ein Cache eingeschliffen - oder u.U. auch mehrere.
Das OS hat üblicherweise mindestens einen, und manche Mass-Storage Controller haben nochmal einen eigenen (speziell Hardware RAID Controller).

Dann wandert das ganze über's Kabel zur HDD.

Auf der HDD selbst kann dann nochmal ein ähnliches Spiel laufen. Advanced Format HDDs z.B. müssen die Zugriffe die von aussen mit 512 Byte Sektoren reinkommen erstmal in Zugriffe auf die grösseren 4K Sektoren übersetzen. Wobei es wieder passieren kann dass ein "kleiner" Schreibbefehl in einen Read-Modify-Write Ablauf verwandelt wird.
Und was SSDs aufführen ist sowieso komplett irre. Und wie SeppJ schon geschrieben hat gibt's auch hier wieder nen Cache.

^*: Heisst: ja, im C++ Teil wird gepuffert, aber nicht um Zugriffe auf Sektorgrenzen zu erzwingen. Sondern weil es (viel) schneller geht wenn der C++ Teil direkt einen kleinen Cache hat, als wenn für jedes einzelne Byte ein Aufruf einer OS-Funktion gemacht werden muss. Selbst wenn das OS einen wirklich effizienten File-Cache hat.

ps: Natürlich sind C++ Implementierungen möglich die ganz ohne OS auskommen, oder ein OS verwenden das keine byteweisen Zugriffe auf Files erlaubt. In dem Fall muss sich dann die C++ Implementierung selbst darum kümmern die Zugriffe entsprechend zu übersetzen. Auf normalen Desktop-Plattformen ist das aber nicht der Fall. Und auch nicht auf iOS, Android, Windows Phone etc.