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
Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.
Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.
unter "in-core parts of a file" sind die Daten gemeint, im Gegensatz dazu gibt es auch die Metadataten, wie atime, mtime,size...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")?
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
Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.
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.
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.
Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.
Die Beschreibungen von osync findest du beim open-Systemcall: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?
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.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.
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.
Es gibt zwar zu diversen Compilern auch eine Dokumentation der Systemaufrufe, am liebsten verwende ich allerdings immer noch die Manpage.Klausi hat geschrieben: Gibts dafür auch eine offizielle Doku? Ich habe schon ein paar Stunden gegoogelt und nichts wirklich grundlegendes gefunden.
Nach "osync" sucht man dort allerdings vergeblich, wenn man das nicht mit O_SYNC und weiter mit dem "open" Systemaufruf assoziiert.
Gruß
gms
Re: Datei-I/O: Unterschied zw. Flags wie fsync, osync, etc.
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
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