Hallo, ich habe eine Frage dazu, was im Hintergrund passiert, wenn mit fstream eine Binärdatei beschrieben wird. Das Szenario ist folgendes: Ein Rechner bekommt jede Sekunde mehrere Daten. Bei jedem Datenempfang wird eine Funktion angestroßen. Diese analysiert die empfangenen Daten, öffnet je nach Inhalt eine Binärdatei, fügt dort Daten hinzu und schließt die Datei. Ablauf von fstream ist also öffnen, ergänzen, schließen. Ich gehe davon aus, dass beim Ergänzen der Datei nicht einfach Bytes ans Ende angehangen werden können. Bedeutet dies dann, das im Hintergrund ähnlich wie bei realloc(), die Datei gelöscht und eine neue Datei inklusive zusätzlicher Bytes geschrieben wird?
A. R. schrieb: > Ich gehe davon aus, dass beim Ergänzen der Datei nicht > einfach Bytes ans Ende angehangen werden können. Und wieso? Die Douk sagt das es verschiedene Modi gibt: http://www.cplusplus.com/reference/iostream/fstream/fstream/ Ansonsten wäre ausprobieren (mit einer unwichtigen Datei) doch 100x schneller als hier auf Antworten zu warten...
A. R. schrieb: > Ich gehe davon aus, dass beim Ergänzen der Datei nicht einfach Bytes ans > Ende angehangen werden können. Wieso nicht? Wenn im letzten Sektor bzw. Cluster oder Block (je nach Sichtweise) noch Platz ist, werden die neuen Byte dort abgelegt,; ansonsten kommt halt der nächste Block dazu (der bei keinem aktuellen Dateisystem direkt dahinter liegen muß, sondern beliebig irgendwo herumliegen kann - sogar bei FAT). Wo ist das Problem?
Läubi .. schrieb: > Ansonsten wäre ausprobieren (mit einer unwichtigen Datei) doch 100x > schneller als hier auf Antworten zu warten... Ein Neuling in diesem Forum wie du wundert sich noch über solche Fragen, aber das lässt mit der Zeit nach.... Ach, du bist ja gar nicht neu hier. Dann verwundert mich dein Einwand jetzt doch etwas :-)
Man wird doch noch auf Einsicht hoffen dürfen :-)
Weil Weihnachten ist, sei es dir nachgesehen. Aber sonst sind solche Gedanken nicht gut für den Blutdruck!
>Und wieso? Die Douk sagt das es verschiedene Modi gibt: >http://www.cplusplus.com/reference/iostream/fstream/fstream/ >Ansonsten wäre ausprobieren (mit einer unwichtigen Datei) doch 100x >schneller als hier auf Antworten zu warten... Ich bin mir über die Funktionalität fstream im klaren. Vielleicht ist meine Frage auch schlecht fomuliert. Dir sei versichert, dass ich schon genug ausprobiert habe bevor ich hier gepostet habe. Nur weil fstream es mir ermöglicht, Daten direkt an eine Datei anzuhängen bedeutet dies noch nicht, dass dies immer Sinnvoll ist. Auf diesen Aspekt zielte meine Frage ab. >Wieso nicht? >Wenn im letzten Sektor bzw. Cluster oder Block (je nach Sichtweise) noch >Platz ist, werden die neuen Byte dort abgelegt,; ansonsten kommt halt >der nächste Block dazu (der bei keinem aktuellen Dateisystem direkt >dahinter liegen muß, sondern beliebig irgendwo herumliegen kann - sogar >bei FAT). >Wo ist das Problem? Eben genau das war die Frage. Bzw. ist auch schon die Antwort. Mein Laufwerk ist z. B. NTFS formatiert. Laut Wikipedia ist also ein Standardclustor 4096Bytes groß. Meine Anwendung ergänzt jede Sekunde pro Datei 25Bytes. Also Fallen pro Tag pro Datei 86400 Zugriffe statt. Die Daten kommen nicht jede Sekunde und es findet eine Interpolation statt also sind es geschätzt 20000Zugriffe pro Tag pro Datei. Pro Datei pro Tag sind das dann 2.160.000Bytes oder 528 Cluster. Da ich ca. 100 verschiedene Daten beschreibe (es sind 100 verschiedene Datenquellen verfügbar) finden also pro Sekunde maximal 100Schreibvorgänge statt. Wobei vor jedem Schreibvorgang zuerst die Datei auf existenz geprüft wird und die letzte Messzeit gelesen wird. Das Programm existiert und läuft seit etwa 2 Wochen problemlos. Die Frage ist nun, ob dieses Konzept so sinnvoll ist. Hier fehlen mir leider die Praxiserfahrungen. Es müssen extrem viele Zugriffe auf die Festplatte stattfinden. Im Worst Case besteht eine 2MB große Datei später aus 489 Clustern die sich an verschiedenen Orten der Festplatte befinden. Ich könnte mir vorstellen, zuerst 2MB an Daten im RAM zwischenzuspeichern. Dies würde aber erschweren, jederzeit Zugriff (von einem anderen Rechner) auf diese Daten zu habe.
A. R. schrieb: > Die Frage ist nun, ob dieses Konzept so sinnvoll ist. Hier fehlen mir > leider die Praxiserfahrungen. Möglicherweise ist es sinnvoller, alles in eine Datei zu werfen (ohne dauernd zu öffnen und zu schließen) und davon entkoppelt von einem anderen Programm auseinanderdröseln zu lassen. Es kann auch sein, daß eine DB damit besser zurecht kommt. Andererseits: wenn es so funktioniert, ist es doch auch gut, oder nicht?
A. R. schrieb: > Im Worst Case besteht eine 2MB große Datei später aus 489 Clustern die > sich an verschiedenen Orten der Festplatte befinden. Das ist nicht dein Problem, dafür gibt es ein Dateisystem.
> Es müssen extrem viele Zugriffe auf die Festplatte stattfinden.
Wobei noch gar nicht feststeht, ob diese Zugriffe überhaupt alle
unmittelbar auf die Festplatte durchgeschliffen werden. Zwischen deinem
fstream und der tatsächlichen Festplatte sitzen noch das Betriebssystem
(dort wieder im Speziellen das Dateisystem), der Plattentreiber und
nicht zuletzt auch noch diverse Caches, sowohl im BS als auch in der
Festplatte. Nur weil dein fstream schreibt, heißt das noch lange nicht,
dass sich da jetzt sofort und unmittelbar ein Schreib/Lesekopf der
Platte auf den Weg macht.
Allerdings wird das ständige öffnen und schließen die Zahl an Zugriffen nicht gerade verringern. Wenn du die finale Größe der Datei kennst oder zumindest eine maximale Größe, kannst du auch im voraus eine Datei dieser Größe anlegen und dann später die Daten eben überschreiben, um die Fragmentierung zu reduzieren.
dazu 2 "Gedanken": Defragmentierung: aka: >Das ist nicht dein Problem, dafür gibt es ein Dateisystem. natürlich ist das ein Problem (außer bei SSD) .. es wäre Sinnvoller die Datei immer z.b. 10MBYte wachsen zu lassen, (dazu muss man aber auch noch speichern wo das Dateiende ist) Datensicherheit: wenn man damit leben kann, dass nach einem Stromausfall, die Daten von ein paar Minuten weg sind, würde ich nicht jedes mal öffnen/schließen andererseites (wenn wirklich jeder wert wichtig ist, muss man bei (vorallem bei) NTFS eh aufpassen, und den schreib-cache "umgehen" ..) (komisch finde ich übrigens, dass noch keiner eine datenbank (mysql) vorgeschlagen hat, dass ist normalerweise immer das erste dass irgendjemand bei solchen threads postet... ;-) edit: ich sehe gerade, dass doch schon jemand eine DB ins spiel gebracht hat..
Robert L. schrieb: > Datensicherheit: wenn man damit leben kann, dass nach einem > Stromausfall, die Daten von ein paar Minuten weg sind, würde ich nicht > jedes mal öffnen/schließen Das verstehe ich jetzt nicht. Kannst du das mal erklären? MfG Klaus
solange die Datei offen ist, werden die Daten nicht auf die platte geschrieben (bzw. nur "sporadisch") bei FAT32 hast du dann nach einem Stromausfall inkonsistente Daten bei (neueren) NTFS hast du http://de.wikipedia.org/wiki/Journaling und damit den "letzten" konsistenten stand.. wobei eben auch beim schließen einer Datei nicht SOFORT geschrieben wird (wegen schreib-cache) deshalb muss man NTFS formatierte usb-festplatten auch "sicher trennen" usw.
Robert L. schrieb: > deshalb muss man NTFS formatierte usb-festplatten auch "sicher trennen" > usw. nö, denn seit Vista sind Wechseldatenträger die option "für schnelles entfernen" aktiviert.
Bevor es hier entgleist: 1. Es geht nicht um Wechseldatenträger. Ob auf einem USB irgendwas aktivirt ist oder nicht, hat doch mit diesem Thread nichts zu tun. 2. Es geht um viele Dateien (Größenordnung 100). Da ist es nicht sinnvoll, alle Dateien geöffnet zu halten.
Klaus Wachtler schrieb: > Es geht um viele Dateien (Größenordnung 100). Da ist es nicht > sinnvoll, alle Dateien geöffnet zu halten. warum nicht, selbst dos kannte damit schon umgehen. 100 ist ja wohl nicht viele. Finde ich zu mindest sinnvoller als ständig zu öffnen und zu schießen. Auch die Abfrage ob die Datei braucht man eigentlich nur einmal zu machen. Die Frage ist aber ob gleichzeitig mit den Datein etwas anders gemacht wird.
Interessant ich hab allerdings mit Win7 eine NTFS USB Festplatte (eigentlich eine ssd die testhalber in einem USB externen Gehäuse war) beschrieben und dabei festgestellt, dass win7 zuerst mit 70mbyte/sekunde geschrieben hat und dann immer wieder pausen gemacht hat (Vorallem ganz am schluss) als ich diese dann (testhalber) mit Fat32 formatiert hatte, wurde konstant mit 20-30 (es war ein billig externens gehäuse, was nicht mehr her gibt) geschrieben wurde.. auch wenn es so sein sollte wie du schreibt sollte man trotzdem "sicher trennen" (um sicher zu stellen, dass nicht irgend ein Programm irgend eine Datei offen hat..) >1. Es geht nicht um Wechseldatenträger. >Ob auf einem USB irgendwas aktivirt ist oder nicht, hat doch mit diesem >Thread nichts zu tun. doch, es sollte dir allerdings nur als BEISPIEL dienen, damit du versteht, was bei einem Stromausfall passiert (was sich mit einer usb oder esata Festplatte einfach, einfacher simulieren lässt)
Robert L. schrieb: > und dabei festgestellt, dass win7 zuerst mit 70mbyte/sekunde geschrieben > hat > und dann immer wieder pausen gemacht hat > (Vorallem ganz am schluss) > > als ich diese dann (testhalber) mit Fat32 formatiert hatte, wurde > konstant mit 20-30 (es war ein billig externens gehäuse, was nicht mehr > her gibt) geschrieben wurde.. wenn es ein billig externens gehäuse war, dann war ist vermutlich noch USB2.0 dann kann etwas mit den 70Mbyte/s nicht stimmen.
sag ich ja
+
>und dann immer wieder pausen gemacht hat
(ich war/bin einfach der Meinung, dass das der schreib Cache ist..)
Robert L. schrieb: > dazu 2 "Gedanken": > > Defragmentierung: > aka: >Das ist nicht dein Problem, dafür gibt es ein Dateisystem. > > natürlich ist das ein Problem (außer bei SSD) .. Gerade bei SSDs ist es ein Problem. Klaus Wachtler schrieb: > Bevor es hier entgleist: > 1. Es geht nicht um Wechseldatenträger. > Ob auf einem USB irgendwas aktivirt ist oder nicht, hat doch mit diesem > Thread nichts zu tun. > 2. Es geht um viele Dateien (Größenordnung 100). Da ist es nicht > sinnvoll, alle Dateien geöffnet zu halten. Ich finde es eher nicht sinnvoll, alle 100 Dateien einmal pro Sekunde zu öffnen und wieder zu schließen.
Rolf Magnus schrieb: >> Defragmentierung: >> aka: >Das ist nicht dein Problem, dafür gibt es ein Dateisystem. >> >> natürlich ist das ein Problem (außer bei SSD) .. > > Gerade bei SSDs ist es ein Problem. warum sollte Fragmentierung bei SSD ein Problem sein? Da die Adresssierungszeit fast 0 ist spielt es doch keine Rolle wie die Daten angeordnet sind.
Peter II schrieb: > Rolf Magnus schrieb: >>> Defragmentierung: >>> aka: >Das ist nicht dein Problem, dafür gibt es ein Dateisystem. >>> >>> natürlich ist das ein Problem (außer bei SSD) .. >> >> Gerade bei SSDs ist es ein Problem. > > warum sollte Fragmentierung bei SSD ein Problem sein? Weil eine SSD die Daten intern in viel größeren Blöcken als das Dateisystem verwaltet. Und wenn nur ein Teilblock geschrieben werden soll, bedeutet das für die SSD, daß sie erst den ganzen Block in einen Zwischenspeicher einlesen, den neuen Teil einsetzen und dann das ganze wieder rausschreiben muß.
Rolf Magnus schrieb: > Weil eine SSD die Daten intern in viel größeren Blöcken als das > Dateisystem verwaltet. wenn er aber eh immer 50byte nur auf einmal rausschreiben will, spielt das überhaupt keine Rolle. Dann dabei wird niemals ein Block voll. Es muss also immer erst gelesen werden. Wie groß sind eigentlich die Blöcke in der SSD? Ich hätte gedacht 4k und dann würde es sehr gut zum NTFS passen.
Peter II schrieb: > wenn er aber eh immer 50byte nur auf einmal rausschreiben will, spielt > das überhaupt keine Rolle. Dann dabei wird niemals ein Block voll. Es > muss also immer erst gelesen werden. Wenn die Datei allerdings gelöscht wird, bleibt danach quasi eine "Kraterlandschaft" zurück, die dann für das Anlegen neuer Dateien nicht gerade ideal ist. > Wie groß sind eigentlich die Blöcke in der SSD? Ich hätte gedacht 4k und > dann würde es sehr gut zum NTFS passen. Es gibt zwei Blockgrößen. Eine "Page" ist meist 4k groß, aber gelöscht werden können nur größere Blöcke, sogenannte "Erasable Blocks", für die laut Wikipedia gilt: > Alle seit 2009 gängigen MLC-Laufwerke verwenden jedoch durchgängig Größen > von 512 KB.
stimmt, bei SSD hab ich mich schlecht ausgedrückt: Fragmentierung ist KEIN problem aber immer nur 25 Byte schreiben, natürlich schon. >Wie groß sind eigentlich die Blöcke in der SSD? Ich hätte gedacht 4k und >dann würde es sehr gut zum NTFS passen. kann man nicht mehr sagen/bestimmen weil die Daten bei den z.b. neuen Sanforce? auch komprimiert werden (automatisch)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.