Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
Klausi
Beiträge: 17
Registriert: 14.01.2004 11:33:21

Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.

Beitrag von Klausi » 10.06.2008 14:03:26

Hallo,

gibt es irgendwo eine Definition oder vergleichende Erklärung für "fsync", "osync", "fdatasync", "sync", "async", etc?

Die Unterschiede sind mir nicht ganz klar.
Wenn ich z.B. die Manpage von fsync lese, scheint mir hier der Buffer-cache umgangen/geleert zu werden oder doch nicht ganz (was sind "in-core parts of a file")?

Mit einem Programm wie lmdd machen fsync=1 oder osync=1 jedenfalls einen sehr großen Unterschied.
Aber worin besteht der genau?

Besten Dank

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.

Beitrag von gms » 10.06.2008 16:16:58

Klausi hat geschrieben: Die Unterschiede sind mir nicht ganz klar.
Wenn ich z.B. die Manpage von fsync lese, scheint mir hier der Buffer-cache umgangen/geleert zu werden oder doch nicht ganz (was sind "in-core parts of a file")?
unter "in-core parts of a file" sind die Daten gemeint, im Gegensatz dazu gibt es auch die Metadataten, wie atime, mtime,size...

fsync .. synchronisiert alle modifizierten Buffer-Cache Pages von einer speziellen Datei auf die Platte, Metadaten werden hier auch synchronisiert, der aufrufende Prozeß wartet bis der Schreibvorgang beendet ist.
fdatasync ... wie fsync, jedoch werden keine Metadaten synchronisiert, außer diese sind für den Schreibvorgang notwendig, wie z.B wenn sich die Größe der Datei dadurch ändert.
sync .. wie fsync, jedoch für alle Dateien, auf das Ende des Schreibvorgangs wird jedoch nicht gewartet
osync ... synchronisiert jeden Schreibvorgang einer speziellen Datei sofort auf die Platte
async ... die obigen Definitionen beziehen sich auf die Systemaufrufe aus der libc und die äquivalenten lmdd-Optionen, async ist etwas anderes. Damit könnte entweder "Asynchronous (File-)IO" oder die Mountoption "async" gemeint sein

Gruß
gms

edit: osync ist eigentlich kein eigener Systemaufruf, sondern ein spezielles Flag "O_SYNC" mit dem eine Datei geöffnet werden kann

Klausi
Beiträge: 17
Registriert: 14.01.2004 11:33:21

Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.

Beitrag von Klausi » 10.06.2008 17:31:42

Hallo gms,

vielen Dank für die schnelle Info!

fsync, fdatasync u. sync sind mir jetzt klar.

Bei osync nehme ich an, du meinst mit "jedem Schreibvorgang" jeden einzelnen Schreibblock (?).
D.h. nur hier wird der Buffer-Cache tatsächlich umgangen oder sofort wieder geleert, während er bei den anderen Optionen erstmal gefüllt und dann die größere Menge auf Platte geschrieben wird, ohne dass noch Daten nachkommen, falls der Cache nicht bereits voll ist?

Gibts dafür auch eine offizielle Doku? Ich habe schon ein paar Stunden gegoogelt und nichts wirklich grundlegendes gefunden. Irgendwo hatte ich auch eine Tabelle gesehen mit Performance-Messungen für async und noch jede Menge weiteren Optionen. Nur dass jemand mal 'ne Definition dafür mitliefert, ist mir bisher nicht aufgefallen.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.

Beitrag von gms » 10.06.2008 19:23:18

Klausi hat geschrieben: Bei osync nehme ich an, du meinst mit "jedem Schreibvorgang" jeden einzelnen Schreibblock (?).
D.h. nur hier wird der Buffer-Cache tatsächlich umgangen oder sofort wieder geleert, während er bei den anderen Optionen erstmal gefüllt und dann die größere Menge auf Platte geschrieben wird, ohne dass noch Daten nachkommen, falls der Cache nicht bereits voll ist?
Die Beschreibungen von osync findest du beim open-Systemcall:
man open hat geschrieben: O_SYNC Die Datei wird im “synchron I/O Modi” geöffnet. Jeder write über
die zurückgegebene Dateibeschreibung wird den aufrufenden Prozess
solange anhalten, bis die Daten physikalisch auf die angesprochene
Hardware geschrieben ist.
der Buffer-Cache wird hier allerdings genauso verwendet, wie wenn die Datei "normal" also ohne O_SYNC geschrieben wird. Auch bei den anderen Schreibvorgängen, bleibt der Buffer so lange erhalten, bis er für "wichtiger" Dingen benötigt wird.
Du stellst dir das anscheinend eher wie einen Stream-Cache vor. Dieser wird auch durch Lese- oder Schreiboperationen gefüllt werden. Durch fflush oder fclose werden dann die Daten geschrieben und ein write-Systemaufruf abgesetzt. Dadurch werden die Daten dann vom Stream-Cache in den Buffer-Cache geschrieben werden.

Den Buffer-Cache kann man umgehen, wenn man eine Datei mit dem O_DIRECT Flag öffnet. ( es muß dann allerdings auch noch in Pagesize-Blöcken gelesen oder geschrieben werden ). Ja und O_ASYNC gibts natürlich auch.
Klausi hat geschrieben: Gibts dafür auch eine offizielle Doku? Ich habe schon ein paar Stunden gegoogelt und nichts wirklich grundlegendes gefunden.
Es gibt zwar zu diversen Compilern auch eine Dokumentation der Systemaufrufe, am liebsten verwende ich allerdings immer noch die Manpage.
Nach "osync" sucht man dort allerdings vergeblich, wenn man das nicht mit O_SYNC und weiter mit dem "open" Systemaufruf assoziiert.

Gruß
gms

Klausi
Beiträge: 17
Registriert: 14.01.2004 11:33:21

Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.

Beitrag von Klausi » 11.06.2008 14:12:15

Hallo gms,

nochmals besten Dank.

Ich habe nun im Internet unter "man open" einiges gefunden. Auf meinem System kommt dann open(1) openvt (?). Ok, nun hat mir jemand gesagt, ich muß "man 2 open" eingeben.

Was ich eigentlich mit der letzten Frage meinte:
Ist bei O_SYNC "jeder Schreibvorgang" oder "jeder write" das Schreiben von genau soviel Bytes wie als Blockgröße in der Anwendung definiert? Z.B. dd ("bs="), lmdd ("bs="), bonnie ("chunk size") oder iozone ("record size")?

Ich will eigentlich den "Arbeitsspeicher/RAM" auch bei kleinen Dateien umgehen, der sonst eine unrealistische Performancemessung hervorbringt. Das ist doch der "Buffer-Chache" oder? Ist das mit O_SYNC zumindest annähernd realistisch oder sollte man dann O_DIRECT oder ??? verwenden?

Du schreibst von einem Stream-Cache. Ist das der Prozessor-Cache (Option "-p" bei iozone)? Wie sehe ich wie groß der ist? Macht es Sinn diesen für Performancemessungen durch fflush oder fclose zu umgehen?

Grüße
Klausi

Antworten