Hi liebe Forengemeinde! Ich habe ein Linux betriebenes ARM-Board welches in unregelmäßigen Abständen (5sek - 10 min) Daten auf einen USB Stick speichert. Nun bin ich auf der Suche nach einem Dateisystem bei dem es möglich ist den USB Stick im laufendem Betrieb, im worst-case unter einem Schreibvorgang abzuziehen. Falls eine definierte Anzahl von Bytes verloren geht, z.B.: die letzte Transaktion, ist das OK. Wichtig ist das derdieser Bereich aber beschreibbar bleibt und keine "Reperatur"/(umfangreicher)"Check" des Datenträgers erforderlich wird. EXT3?
http://de.wikipedia.org/wiki/Ext3 ich hätte gesagt ja, wobei "Journalingstufe= full" sein müsste:..
Gast
#3002728
Was hat das mit Programmierung zu tun???
Hab' eh überlegt es in PC Hard- & Software zu stellen... wie auch immer jetzt is es da vll. verschiebt es jemand... Ext3 war ein schnellschuß von mir. Das ganze soll ja Windows kompatibel sein. Also wohl eher NTFS mit NTFS-3G, die Frage ist ob ich da das Journaling so benützen kann, dass im schlimmsten Fall nur die Daten verloren sind die während des Abziehens geschrieben hätten werden sollen.
Gast
#3002758
wenn man immer die die gleiche Datei schreibt. Also nur 1 Datei auf dem Stick. Dann sollte das dateisystem egal sein. Es müssen keinen änderung am Filesystem vorgnommen werden. Dann kann man sich selber in der Datei eine Struktur überlegen wo man am anfang reinschreibt, wo die letzen daten geschrieben wurden. Dann kann man FAT, FAT32, FAT16, NTFS nehmen.
Peter II schrieb: > Also nur 1 Datei auf dem > Stick. Dann sollte das dateisystem egal sein. Es müssen keinen änderung > am Filesystem vorgnommen werden. Das gilt aber nur, wenn die Größe der Datei nicht geändert wird.
Gast
#3002782
Malte S. schrieb: > Das gilt aber nur, wenn die Größe der Datei nicht geändert wird. ja, hätte ich noch dazu schreiben müssen. Also am besten 1 Datei die die gesamte größe des Sticks hat.
Gast
#3003006
> Also am besten 1 Datei die die gesamte größe des Sticks hat.
Da wäre ich noch nicht so sicher, daß es IMMER bei JEDEM Sick klappt. Da
der USB-Stick ja aus Controller und Speicher besteht, bin ich ja nicht
sicher, ob der Controller definiert immer ALLES bis in den Speicher
bekommt wenn der Strom weg ist.
Da würde ich mindestens 2 verschiedene Sticks benutzen, damit evtl. noch
einer übrig bleibt im Fehlerfall.
Gast
#3003033
oszi40 schrieb: > Da wäre ich noch nicht so sicher, daß es IMMER bei JEDEM Sick klappt. Da > der USB-Stick ja aus Controller und Speicher besteht, bin ich ja nicht > sicher, ob der Controller definiert immer ALLES bis in den Speicher > bekommt wenn der Strom weg ist. und? das war wollte auch niemand! > Falls eine definierte Anzahl von Bytes verloren geht, z.B.: die letzte > Transaktion, ist das OK.
Peter II schrieb: > Malte S. schrieb: >> Das gilt aber nur, wenn die Größe der Datei nicht geändert wird. > > ja, hätte ich noch dazu schreiben müssen. Also am besten 1 Datei die die > gesamte größe des Sticks hat. Das mit einer Datei ist eine gute Idee, warum diese aber eine fixe Größe bzw. den ganzen Stick belegen muß verstehe ich nicht. Hatte an folgenden Dateibeginn gedacht: WRITING|START|END|WRITING|START|END|DATA....|DATA.... Writing... Bit das definiert ob gerade geschrieben wird oder nicht start... beginn des blocks end... ende des blocks Es wird immer abwechseld die erste Struktur und die zweite benutzt. Logischerweise wir immer das bit Writing zuerst gesetzt dann start und end dann die daten und dann wieder writing zurückgesetzt. Wozu brauch ich die feste Größe?
Gast
#3003079
Erwin W. schrieb: > Das mit einer Datei ist eine gute Idee, warum diese aber eine fixe Größe > bzw. den ganzen Stick belegen muß verstehe ich nicht. weil beim vergrößern einer Datei sich die Daten des Dateisystems ändern müssen, wenn dort etwas schieft geht ist nicht mehr sichergestellt das es danach noch lesbar ist.
Gast
#3003087
Erwin W. schrieb: > Wozu brauch ich die feste Größe? das filesystem legt die daten nicht zwangsläufig linear nacheinander ab. um sich in dem chaos wieder zurecht zu finden, schreibt das filesystem diverse daten, wenn du das system beim schreiben der informationen mit dem abziehen des sticks überrascht, dann wird das ganze kompliziert (und ntfs ist nicht unbedingt dafür entworfen worden). wenn die datei immer gleich gross ist, dann verminderst du das risiko ein wenig. alles in allem dürfte es einfacher sein wenn du einfach direkt auf blockebene schreibst, dann hast du die ganzen probleme nicht.
Wenn Du die Anforderung der Windows-Kompatibilität rauskriegst, vielleicht http://en.wikipedia.org/wiki/NILFS
Gast
#3003125
Erwin W. schrieb: > Wozu brauch ich die feste Größe? Peter meint wahrscheinlich, daß Du dann immer den selben logischen Speicherort erreichst ohne das Directory zu verändern. Ob nicht beim Schreiben defekt markierte Blöcke zu ungewollten Veränderungen führen? Ein Journaling-Dateisystem kann zwar vieles auf logischer Ebene ausbügeln, ob jedoch die durch Spannungsausfall fehlerhaft gewordenen Zellen im Speicher immer mehr werden wird erst die Erfahrung zeigen mit dem konkreten Stick. http://www.techwriter.de/thema/usb-mem0.htm#lebensdauer
Da habt Ihr recht, fixe Größe ergibt sinn. - Warum aber den ganzen Datenträger? Auf Blockebene schreiben scheint mir keine Option, da das ganze unter windows ohne spezielle mechanismen lesbar sein soll. - Und wie ist das mit dem Schreiben im Detail: Nehmen wir mal an jemand zieht den Stick unter einem Schreibvorgang ab. Im Normalfall sollten die Pins der Stromversorgung am längsten sein. D.h Zuerst sind die I/Os weg --> Speichercontroller bekommt keinen Input mehr von USB muß aber die vorhanden Operationen noch ausführen da er ja auf Blockebene (Wear Leveling, Flash Speicher an sich... ) ließt und schreibt --> Könnte das nicht ein Problemen sein? Oder sind neue Datenblöcke sowieso immer in einem neuem Block und die Bytes dazwischen sowieso vom Controller ausgeblendet. - Oder ist das Abziehen eh so "langsam", dass der Controller sowieso noch genug Zeit (bzw. die kondensatoren groß genug damit er noch Saft hat) hat den Block fertig zu löschen/schreiben.
Erwin W. schrieb: > Oder ist das Abziehen eh so > "langsam", dass der Controller sowieso noch genug Zeit (bzw. die > kondensatoren groß genug damit er noch Saft hat) hat den Block fertig zu > löschen/schreiben. Wenn man sich mal so einen Stick ansieht, sind (ohne jetzt die Schaltung nachzuvollziehen) meistens nur ein "großer" Bulk-Kondensator und einige Entkopplungs-Cs auf der Platine, gesamt vielleicht in der Größenordnung 20 uF - 50 uF, je nach NAND-Flash brauchen die ~ 1 ms bis 2 ms zum Löschen eines Blocks (z.B. 128 kiB) und dann z.B. ~10 ms zum neuen Schreiben der Daten... ältere NANDs zogen dabei etwa 20 mA (heutige mit Controller wesentlich mehr, einfach mal nach einer längeren Kopieraktion anfassen). Angenommen es sind 100 mA (NAND + Controller) und die Teile arbeiten noch zuverlässig, wenn die Spannung 500 mV unter der normalen Spannung liegt. Wenn ich mich nicht verrechnet habe ist das nach ~ 250 us der Fall...
Ich weiß nicht ob das zu deiner Anwendung passt, aber du brauchst nicht unbedingt ein Dateisystem auf einem USB-Stick. Du kannst die Daten auch einfach so draufschreiben. Checks sind dann jedenfalls nicht notwendig. ;)
Da hatte ich mich unter http://serverfault.com/questions/466169/ schon zu ausgelassen, da hat jemand ziemlich genau dasselbe Problem gehabt...