Probleme bei CreateFile mit FILE_FLAG_WRITE_THROUGH

[WiWo]

Ich habe in einem Projekt eine Hilfsdatei, die zur Synchronisation bestimmter Aufgaben von mehreren Netzwerk-Usern verwendet wird. Seit einiger Zeit verwende ich bei der Datei-Öffnung das Flag FILE_FLAG_WRITE_THROUGH um mehr Sicherheit zu haben, dass Änderungen schnell bei allen Usern ankommen. FILE_FLAG_NO_BUFFERING verwende ich nicht. Seit die Version ausgerollt wurde, gab es von einigen Kunden Beschwerden, dass genau mit diesem Mechanismus was nicht stimmt. Ich konnte das erst nachstellen, nachdem ich hier ein bewusst langsames Netz aufgebaut habe. Es kommt dann bei viel Traffic manchmal zu Datei-Schreibfehlern mit dem Fehlercode 554 (ERROR_CANT_WAIT), zu dem ich dummerweise keine brauchbare Beschreibung gefunden habe. Auch konnte ich nirgends warnende Hinweise bezüglich FILE_FLAG_WRITE_THROUGH finden.
Nun, ich verwende jetzt erstmal das Flag nicht mehr, aber wollte das hier mal posten; vielleicht für andere als hilfreichen Tipp. Und falls jemand zu dieser Thematik mehr Infos hat, bin ich sehr interessiert daran.

[himitsu]

Das hat rein garnichts mit schnell zu tun.
Im Gegenteil, es ist sogar langsamer.
Wenn die Anderen es aus dem FileCache des OS ziehen, ist es sofort da.


Wenn z.B. das Zielsystem es verlangt, dass der Cache genutzt wird, bzw. nicht auf das erfolgreiche Schreiben gewartet werden kann, dann knallt es so natürlich, wenn man was verlangt, was nicht geht. (Netzlaufwerke, virtuelle Festplatten, Dateiverschlüsselung, ...)

FILE_FLAG_NO_BUFFERING: Dann müßte hier auch noch zwangsweise mit vollen/vollständigen Sektoren geschrieben werden. (Blockgrößen, softwareseitiges Ausgabebuffering usw.)


Am Buffering rumzupfuschen hat eigentlich vorwiegend dann vorteile, wenn es um große Datenmengen oder um sehr viele Dateien geht, welche anschließend (länger) nicht mehr angefasst werden,
also das Gegenteil von dem, was du vor hast.






Aber wenn es unbedingt sein muß,
dann vielleicht stattdessen ein FlushFileBuffers vor dem Close.

[WiWo]

@himitsu
"schneller" war vielleicht falsch ausgedrückt. Die Support-Leute haben ab und zu Fälle aufzuklären, bei denen irgendein Buchungsvorgang beim Kunden ein Problem hatte. Meist waren dann viele User gleichzeitig im System und die Szenarien können sehr komplex sein. Der Schreibzugriff per WRITE-THROUGH war tatsächlich ein Versuchsballon; ich hätte allerdings keine Probleme damit erwartet. NO-BUFFERING wollte ich aus den von Dir beschriebenen Gründen nicht verwenden.
Typische Installationen unserer Anwender sind entweder über RDS auf Windows-Server oder per Windows-Client/Server oder auch gemischt. Die Server sind inzwischen meist so ausgeführt, dass virtuelle Server auf einer physikalischen Maschine laufen. Und vermutlich hat da jeder Server sein eigenes Filecaching und der Client nochmal. Damit kann und will ich aber auch gar nichts zu tun haben und unsere Vorgabe ist nur, dass es sich um Windows-Server handeln muss. Es gibt natürlich auch User, die ein NAS verwenden, aber dafür geben wir keine Funktions-Garantie.
Den ERROR_CANT_WAIT-Fehler, den ich bei Verwendung von FILE_FLAG_WRITE_THROUGH bekomme, tritt in einer Windows zu Windows-Umgebung auf und bei mir nur bei einem Stresstest. Schon bei einer Wiederholung des Schreivorgangs nach diesem Fehler kommt der Fehler nicht mehr. Dokumentiert ist das leider nirgends, zumindest hab ich nichts gefunden. Ich habe übrigens auch überprüft, dass der Schreibvorgang bei diesem tatsächlich nicht durchgeführt wurde.
Wo übrigens das Ändern an der Bufferung tatsächlich hilfreich ist, ist beim sequentiellen Verarbeiten großer Dateien mit FILE_FLAG_SEQUENTIAL_SCAN. Und soweit ich feststellen konnte, bringt es zumindest keinen Nachteil bei kleinen Dateien.

[himitsu]

Wenn das Caching vorwiegend im Host ist, dann wäre es für Zugriffe aus unterschiedlichen VMS und Netzwerkfreigaben idealer sein, als wenn JEDER nochmal seinen eigenen Cache nutzt.


Das FILE_FLAG_NO_BUFFERING ist vor allem für's Lesen.
Ich hätte aber manchmal gern eine Mischform dafür. (Wenn schon im Cache, dann das benutzen, und ansonsten nicht im Cache belassen/ablegen, wenn neu gelesen ... ohne füllt man sinnlos den Cache und schmeißt vielleicht unnötig Anderes raus und mit wird immer "neu" gelesen)



FILE_FLAG_RANDOM_ACCESS und FILE_FLAG_SEQUENTIAL_SCAN sind vor allem dafür da, um Windows mitzuteilen, das man etwas bestimmtes macht,
damit es die Cache-Strategie/Methode anpasst.

Leider kann, aber muß Windows/Treiber darauf hören und kann es auch ignorieren.
Aber per se besagt FILE_FLAG_SEQUENTIAL_SCAN, dass man immer nur grade durchläuft und es nicht nötig zurückliegende Daten im Cache zu behalten (oder extrem weit voraus), weil man sagt verspricht, dass man den Cursor nicht zurücksätzen wird.



Vielleicht könnte/sollte man auch nochmal das Konzept überdenken, wenn mit solchen Problemen zu rechnen ist?