Was passiert hinter den Kulissen während der Festplatten-I/O?

Question 1

Was passiert hinter den Kulissen, wenn ich nach einer Position in einer Datei suche und eine kleine Datenmenge (20 Bytes) schreibe?

Mein Verständnis

Meines Wissens ist die kleinste Dateneinheit, die von einer Festplatte geschrieben oder gelesen werden kann, ein Sektor (traditionell 512 Bytes, aber dieser Standard ändert sich jetzt). Das bedeutet, dass ich zum Schreiben von 20 Bytes einen ganzen Sektor lesen, einen Teil davon im Speicher ändern und zurück auf die Festplatte schreiben muss.

Dies erwarte ich bei ungepufferter E / A. Ich erwarte auch, dass gepufferte E/A ungefähr dasselbe tun, aber seien Sie klug mit seinem Cache. Also hätte ich gedacht, dass, wenn ich die Lokalität durch zufällige Suchvorgänge und Schreibvorgänge aus dem Fenster blase, sowohl gepufferte als auch ungepufferte E / A eine ähnliche Leistung haben sollten … vielleicht mit ungepufferter etwas besserer Leistung.

Andererseits weiß ich, dass es für gepufferte E/A verrückt ist, nur einen Sektor zu puffern, also könnte ich auch erwarten, dass es schrecklich funktioniert.

Meine Bewerbung

Ich speichere Werte, die von einem SCADA-Gerätetreiber gesammelt wurden, der Remote-Telemetrie für mehr als hunderttausend Punkte empfängt. Es gibt zusätzliche Daten in der Datei, sodass jeder Datensatz 40 Byte groß ist, aber nur 20 Byte davon müssen während einer Aktualisierung geschrieben werden.

Benchmark vor der Implementierung

Um zu überprüfen, ob ich mir keine brillant überentwickelte Lösung ausdenken muss, habe ich einen Test mit ein paar Millionen zufälligen Datensätzen durchgeführt, die in eine Datei geschrieben wurden, die insgesamt 200.000 Datensätze enthalten könnte. Bei jedem Test wird der Zufallszahlengenerator mit demselben Wert gesät, um fair zu sein. Zuerst lösche ich die Datei und fülle sie auf die Gesamtlänge (ca. 7,6 MB) auf, mache dann eine Schleife ein paar Millionen Mal und übergebe einen zufälligen Datei-Offset und einige Daten an eine von zwei Testfunktionen:

void WriteOldSchool( void *context, long offset, Data *data )
{
    int fd = (int)context;
    lseek( fd, offset, SEEK_SET );
    write( fd, (void*)data, sizeof(Data) );
}

void WriteStandard( void *context, long offset, Data *data )
{
    FILE *fp = (FILE*)context;
    fseek( fp, offset, SEEK_SET );
    fwrite( (void*)data, sizeof(Data), 1, fp );
    fflush(fp);
}

Vielleicht keine Überraschungen?

Das OldSchool Methode hat sich durchgesetzt – mit Abstand. Es war über 6-mal schneller (1,48 Millionen gegenüber 232000 Datensätzen pro Sekunde). Um sicherzustellen, dass ich nicht auf Hardware-Caching gestoßen bin, habe ich meine Datenbankgröße auf 20 Millionen Datensätze (Dateigröße von 763 MB) erweitert und die gleichen Ergebnisse erzielt.

Bevor Sie auf den offensichtlichen Anruf hinweisen fflush, lassen Sie mich sagen, dass das Entfernen keine Wirkung hatte. Ich nehme an, das liegt daran, dass der Cache übergeben werden muss, wenn ich weit genug weg suche, was ich die meiste Zeit tue.

So was ist los?

Es scheint mir, dass die gepufferte E / A einen großen Teil der Datei lesen (und möglicherweise vollständig schreiben) muss, wenn ich versuche zu schreiben. Da ich seinen Cache kaum ausnutze, ist dies äußerst verschwenderisch.

Außerdem (und ich kenne die Details des Hardware-Cachings auf der Festplatte nicht), wenn die gepufferte E / A versucht, eine Reihe von Sektoren zu schreiben, wenn ich nur einen ändere, würde dies die Effektivität des Hardware-Cache verringern.

Gibt es da draußen Festplattenexperten, die das besser kommentieren und erklären können als meine experimentellen Ergebnisse? =)

Question 2

Tatsächlich sieht es zumindest auf meinem System mit GNU libc so aus, als würde stdio 4kB-Blöcke lesen, bevor es den geänderten Teil zurückschreibt. Scheint mir falsch zu sein, aber ich kann mir vorstellen, dass jemand dachte, dass es damals eine gute Idee war.

Ich habe das überprüft, indem ich ein triviales C-Programm geschrieben habe, um eine Datei zu öffnen, ein paar Daten einmal zu schreiben und zu beenden; dann lief es unter strace, um zu sehen, welche Systemaufrufe es tatsächlich ausgelöst hat. Beim Schreiben mit einem Offset von 10000 sah ich diese Systemaufrufe:

lseek(3, 8192, SEEK_SET)                = 8192
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1808) = 1808
write(3, "hello", 5)                    = 5

Scheint, dass Sie für dieses Projekt bei der Low-Level-I/O im Unix-Stil bleiben wollen, oder?

Question 3

Die C-Standardbibliotheksfunktionen führen eine zusätzliche Pufferung durch und sind im Allgemeinen eher für Streaming-Lesevorgänge als für zufällige E/A optimiert. Auf meinem System ~~Ich beobachte nicht die falschen Anzeigen, die Jamey Sharp gesehen hat~~ Ich sehe nur falsche Lesevorgänge, wenn der Offset nicht auf eine Seitengröße ausgerichtet ist – es könnte sein, dass die C-Bibliothek immer versucht, ihren E / A-Puffer auf 4 KB oder so ausgerichtet zu halten.

Wenn Sie in Ihrem Fall viele zufällige Lese- und Schreibvorgänge in einem relativ kleinen Datensatz durchführen, sind Sie wahrscheinlich am besten damit bedient pread/pwrite um zu vermeiden, Systemaufrufe suchen zu müssen, oder einfach mmapDatenmenge speichern und in den Speicher schreiben (wahrscheinlich am schnellsten, wenn Ihre Datenmenge in den Speicher passt).