Hallo zusammen, kennt jemand eine NTFS library, welche auf einen AVR (mega128) passt? Ich möchte gerne NTFS SD-Karten über SPI mit dem AVR beschreiben. Performance ist unkritisch.
Die wird es wohl kaum geben, weil NTFS nicht als Dateisystem für SD Karten vorgesehen ist. Ob und wie gut das funktioniert ist reine Glückssache.
Selbst wenn es da eine taugliche Library gäbe (Evtl. Lässt sich bein NTFS4DOS was abgucken, das ist die ressourcenschonendste Implementation die ich kenne) wird der Speicher knapp... du wirst da auf jeden Fall einen oder mehrere 4k-Blöcke im RAM halten müssen. Oder die SD-Karte mit speziellem Sonderlocken-NTFS in 512er Blockgröße formatieren ... aber wenn die Karte schon ein Spezialformat braucht, dann könnte das ja auch gleich FAT werden.
Danke für die Antworten... Bin auf https://github.com/libyal/libfsntfs gestossen. Kennt jamand diese library? (nicht in bezug auf AVR aber generell). Generell: Dateisysteme ohne Journaling sind eigentlich obsolete, und sind wegen der enormen Datenverlustgefahr eigentlich discouraged. Kennt jemand eine sinnvolle library eines anderen Journaling Datensystems EXT3/4 o.ä. welches auf einen AVR mit default Einstellungen (Blockgrösse etc.) passt. Oder zur Not halt auf einen STM32?
AVR NTFS schrieb im Beitrag #5989924: > Generell: Dateisysteme ohne Journaling sind eigentlich obsolete, und > sind wegen der enormen Datenverlustgefahr eigentlich discouraged. SD-Karten sind sowieso sehr fragil. Die stellen früher oder später spontan den Dienst ein. Das Dateisystem rettet da dann auch nicht mehr viel...
AVR NTFS schrieb im Beitrag #5989924: > Generell: Dateisysteme ohne Journaling sind eigentlich obsolete, und > sind wegen der enormen Datenverlustgefahr eigentlich discouraged. SD Karten sind die Ausnahme, da a) Eher wenig Schreibzyklen verfügbar sind und b) Die meisten Fehler bei FAT relativ simpel repariert werden können Beim AVR passt die FAT Implementation grade so in den RAM - da sehe ich für aufwändigere FS total schwarz. BTW: Wenn $User die Karte beim Schreiben mittendrin entfernt, hat er eine gute Chance hinterher ganz ohne Daten dazustehen. Ich hatte hier einige Karten die bei Experimenten mit der Stromversorgung hinterher total tot waren. Kann aber sein dass das bei modereren Karten nicht mehr so häufig vorkommt.
Selbst wenn es eine NTFS-Bibliothek gibt, wäre ein ATMega128 damit in jeder Hinsicht (Speicher [FLASH/RAM) überlastet. Ob von der vorhandenen Rechenleistung noch was, für Dein eigentliches Problem über bleibt, ist ein anderes Ding.
AVR NTFS schrieb im Beitrag #5989924: > Dateisysteme ohne Journaling sind eigentlich obsolete, und > sind wegen der enormen Datenverlustgefahr eigentlich discouraged. Im Prinzip ist das richtig. Aber konkret aus zwei Gründen falsch: 1. NTFS ist so ziemlich die dämlichste Wahl für ein Filesystem. Außer man ist Windows-only unterwegs. NTFS ist fett und notorisch unterdokumentiert. Und eigentlich wegen NDA-Pflicht nicht open-source implementierbar. 2. die Liste der erlaubten Filesysteme für SD-Karten ist vergleichsweise kurz. Insbesondere enthält sie nicht NTFS. Tatsächlich enthält sie nur verschiedene Inkarnationen von FAT. Wenn man überhaupt ein anderes (nicht offiziell erlaubtes) Filesystem verwenden wöllte, dann eines, das explizit für Flash-Medien gemacht ist. Oder eines, das bekanntermaßen robust ist, wie etwa ext2/3/4.
Das sehe ich genau so. Wobei FAT ist auch sehr robust, solange sich da nur EIN Benutzer (bzw. 1 Task) tummelt. Was bei einem AVR eh praktisch immer so ist.
AVR NTFS schrieb im Beitrag #5989924: > Generell: Dateisysteme ohne Journaling sind eigentlich obsolete, Die typische AVR-Anwendung als Datenlogger hat ja eher nur zwei Operationen: Neue Datei Anlegen (z.B. eine pro Tag) + Datensatz hinten anfügen. es sollte kein Problem sein, diese beiden Aktionen "Journaled" laufen zu lassen, und das Dateisystem trotzdem FAT-Kompatibel zu halten. Zwei File Allocation Tables wären sowieso möglich, da dann die Sekundäre immer als "Write ahead journal" verwenden. Den Root-Verzeichnisssektor könnte man auch doppeln... Kopie anlegen, zweite FAT darauf zeigen lassen, in der ersten FAT als "defekte sektoren" vermerken und umgekehrt. Wenn es jetzt die Karte zu einem ungünstigen Zeitpunkt gezogen wird, könnte man sicherstellen, dass immer wenigstens eine der FAT/Root-Dir Kombinationen gültig ist. Wäre sozusagen "Metadaten-Journaling lite". Für die Daten selber hilft's nix, der letzte Datenblock, an den grad angehängt wurde, kann immernoch kaputtgehen. Damit kann man entweder leben (1 Stunde Temperaturmessdaten weg? so what.) Oder man sichert das zusätzlich auf Applikationsebene, z.B. mmer zwei Dateien pro Tag, und den Datensatz nacheinander an beide anhängen.
Εrnst B. schrieb: > der letzte Datenblock, an den grad angehängt wurde, kann immernoch > kaputtgehen. Wenn du eine SD Karte im laufenden betrieb ziehst oder die Stromversorgung ausfällt, verlierst du typischerweise entweder nichts oder alle Dateien. Das hat mit dem Wear-Levelling der Karte zu tun, kann man nicht mit Disketten vergleichen.
Axel S. schrieb: > 1. NTFS ist so ziemlich die dämlichste Wahl für ein Filesystem. Außer > man ist Windows-only unterwegs. NTFS ist fett und notorisch > unterdokumentiert. Und eigentlich wegen NDA-Pflicht nicht open-source > implementierbar. > > 2. die Liste der erlaubten Filesysteme für SD-Karten ist vergleichsweise > kurz. Insbesondere enthält sie nicht NTFS. Tatsächlich enthält sie nur > verschiedene Inkarnationen von FAT. So die Theorie ... Bis man merkt, dass der Fernseher bei USB-Medien nur FAT und NTFS akzeptiert, kein exFAT, kein ext2 oder ext3. Obwohl der intern sicher Linux-basiert ist. Bei Dateien mit mehr als 4 GByte wird die Auswahl dann recht klein.
A. B. schrieb: > Axel S. schrieb: > >> 1. NTFS ist so ziemlich die dämlichste Wahl für ein Filesystem. Außer >> man ist Windows-only unterwegs. NTFS ist fett und notorisch >> unterdokumentiert. Und eigentlich wegen NDA-Pflicht nicht open-source >> implementierbar. >> >> 2. die Liste der erlaubten Filesysteme für SD-Karten ist vergleichsweise >> kurz. Insbesondere enthält sie nicht NTFS. Tatsächlich enthält sie nur >> verschiedene Inkarnationen von FAT. > > So die Theorie ... Bis man merkt, dass der Fernseher bei USB-Medien nur > FAT und NTFS akzeptiert, kein exFAT, kein ext2 oder ext3. Das ist aber eine ganz andere Baustelle. "USB-Medien" sind etwas anderes als eine SD Speicherkarte. Ein Fernseher ist was anderes als ein AVR. Und wenn du nicht die Wahl hast, welches Filesystem es werden soll, dann hast du halt nicht die Wahl. > Obwohl der intern sicher Linux-basiert ist. Nicht notwendigerweise. Aber eigentlich ist das auch vollkommen egal. Es gibt keinen Grund, das Speichermedium, das eine Schlau-Glotze zur Ablage von Timeshift und sonstigen Aufnahmen verwendet, an einen Computer anschließen zu wollen. Die Daten sind heutzutage verschlüsselt. Wenn man das Fernsehprogramm aufnehmen wöllte, dann würde man besser eine entsprechende Receiver-Karte in einen PC stecken.
Axel S. schrieb: > Das ist aber eine ganz andere Baustelle. "USB-Medien" sind etwas anderes > als eine SD Speicherkarte. Nein, wenn die SD-Karte in einem Kartenleser steckt, eben nicht. > Nicht notwendigerweise. Aber eigentlich ist das auch vollkommen egal. Es > gibt keinen Grund, das Speichermedium, das eine Schlau-Glotze zur Ablage > von Timeshift und sonstigen Aufnahmen verwendet, an einen Computer > anschließen zu wollen. Die Daten sind heutzutage verschlüsselt. Genau anders herum, die SD-Karte wird vom PC befüllt und dann an den Fernseher angeschlossen. Da ist nix verschlüsselt.
Sebastian S. schrieb: > Selbst wenn es eine NTFS-Bibliothek gibt, wäre ein ATMega128 damit in > jeder Hinsicht (Speicher [FLASH/RAM) überlastet. Scheint leider so zu sein. Auch die oben erwähnte ext4 library scheint nicht wirklich mit dem AVR zu funktionieren (habe keinen grossen Aufwand betreiben). Axel S. schrieb: > AVR NTFS schrieb im Beitrag #5989924: >> Dateisysteme ohne Journaling sind eigentlich obsolete, und >> sind wegen der enormen Datenverlustgefahr eigentlich discouraged. > > Im Prinzip ist das richtig. Aber konkret aus zwei Gründen falsch: > > 1. NTFS ist so ziemlich die dämlichste Wahl für ein Filesystem. Außer > man ist Windows-only unterwegs. NTFS ist fett und notorisch > unterdokumentiert. Und eigentlich wegen NDA-Pflicht nicht open-source > implementierbar. > > 2. die Liste der erlaubten Filesysteme für SD-Karten ist vergleichsweise > kurz. Insbesondere enthält sie nicht NTFS. Tatsächlich enthält sie nur > verschiedene Inkarnationen von FAT. Nun mit den Raspis u co. werden SDs erflogreich seit jahren gejournalt. Bei moderneren Flashcontrollern geht dies meines wissens in der Regel auch ohne Probleme. Stefanus F. schrieb: > Wenn du eine SD Karte im laufenden betrieb ziehst oder die > Stromversorgung ausfällt, verlierst du typischerweise entweder nichts > oder alle Dateien. Das hat mit dem Wear-Levelling der Karte zu tun, kann > man nicht mit Disketten vergleichen. Ich habe mal gelesen das selbst SD karten mit Dram und buffer Cs ausgestattet sind. Ob dies generell der Fall ist oder lediglich marketing eines high perf. Herstellers kann ich jedoch nicht sagen. Axel S. schrieb: > Das ist aber eine ganz andere Baustelle. "USB-Medien" sind etwas anderes > als eine SD Speicherkarte. Ein Fernseher ist was anderes als ein AVR. > Und wenn du nicht die Wahl hast, welches Filesystem es werden soll, dann > hast du halt nicht die Wahl. Ich denke wir können die Problemstellung umformulieren: Gesucht: gute, stabile getestete und einfache Journaling FS (ext4 oder NTFS oder gar universell) lib, die so einfach zu verwenden ist wie die klassichen FAT32 libs, und wenn halt nicht auf einen AVR dann halt auf die "nächst" mächtigeren MCUs zu kriegen ist (z.b. STMF4 o. ä.). Ein entsprechender Tipp ist vermutlich für eine relativ grosse Audienz Goldwert, da solange genügend perf verfügbar ist eig nichts gegen die Journaling FS spricht
Naja, der STM32F4 ist aber schon einige Stufen mächtiger als AVR. Eine Nummer höher wäre meiner Meinung nach die STM32F1 oder F3 Serie.
AVR NTFS schrieb im Beitrag #5993453: > Nun mit den Raspis u co. werden SDs erflogreich seit jahren gejournalt. "Erfolgreich" ist relativ. Die *Pis gehören vermutlich mit zu den größten Zerstörern von SD-Karten.
Stefanus F. schrieb: > Naja, der STM32F4 ist aber schon einige Stufen mächtiger als AVR. > > Eine Nummer höher wäre meiner Meinung nach die STM32F1 oder F3 Serie. Absolut korrekt, wenns mit einem F1 geht umso besser. Ich wollte es eigentlich vermeiden einen Hersteller zu nennen und möchte anmerken, dass die Japaner, Texaner etc. sehr konkurenzfähige MCUs zu den Europäern bauen und diese Wahl individuell zu treffen ist und ebenfalls nicht zwingend ARM basiert sein muss (Werbefrei :-)). Es geht lediglich darum die library für ein entsprechendes möglichst tiefes MCU level zu finden.
Dr. Sommer schrieb: > AVR NTFS schrieb im Beitrag #5989924: >> Generell: Dateisysteme ohne Journaling sind eigentlich obsolete, und >> sind wegen der enormen Datenverlustgefahr eigentlich discouraged. > > SD-Karten sind sowieso sehr fragil. Die stellen früher oder später > spontan den Dienst ein. Das Dateisystem rettet da dann auch nicht mehr > viel... Und vor allem sind SD-Karten für genau eine bestimmte Partitionierung und genau ein spezifisches Filesystem mit genau definierten Parametern gebaut, und das ist je nach Größe ein FAT oder exFAT. Deshalb gibt's auch extra dafür ein eigenes offizielles Tool von der SD Association, das die Karten spezifikationskonform formatiert.
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.