Wahl des Dateisystems für GNU / Linux auf einer SD-Karte


31

Ich habe ein eingebettetes ARM-basiertes System, das auf einer SD-Karte läuft. Es ist derzeit Debian GNU / Linux, das ext3 als Dateisystem verwendet. Als ich gerade dabei bin, das System neu zu installieren, habe ich mich gefragt, ob ich zu einem flashfreundlicheren Dateisystem wechseln soll. Ich habe von JFFS2, YAFFS2 und LogFS gehört und sie scheinen alle für den Job geeignet zu sein. Welches würden Sie empfehlen? Außerdem habe ich gehört, dass es viele ext4-Verbesserungen gegeben hat, um SSD-Festplatten besser zu unterstützen. soll ich das so interpretieren, dass ext4 einwandfrei laufen sollte? Woran muss ich in diesem Fall besonders denken?

Ich denke, die Verwendung des Systems ist wichtig. Stellen Sie sich der Allgemeinheit halber jedoch vor, es würde Standard-Desktop-Inhalte ausführen (auch wenn es sich um ein kleines ARM-basiertes System handelt).

Vielen Dank für alle Antworten.

Bearbeiten: Wikipedia sagt mir (in einem "Zitat benötigt" -Statement), dass austauschbare Flash-Speicherkarten und USB-Flash-Laufwerke eingebaute Controller haben, um Verschleißnivellierungen und Fehlerkorrekturen durchzuführen, so dass die Verwendung eines bestimmten Flash-Dateisystems keinen Vorteil bringt . Daher neige ich dazu, mich an ein ext-Dateisystem zu halten.

Antworten:


18

Hervorragender Artikel über Flash-Dateisysteme .

Wichtige Frage, wenn es um Flash-Dateisysteme geht: Was ist Wear Leveling? Wikipedia-Artikel . Grundsätzlich können Sie auf Flash-Disks nur eine begrenzte Anzahl von Schreibvorgängen ausführen, bis der Block fehlerhaft wird. Danach muss das Dateisystem (wenn es auf der Hardware kein integriertes Wear Leveling Management gibt, wie es bei SSDs normalerweise der Fall ist) diesen Block als ungültig markieren und ihn nicht mehr verwenden.

Typische Dateisysteme (z. B. ReiserFS, NTFS, ext3 usw.) sind für Festplatten konzipiert, für die solche Einschränkungen nicht gelten.

JFFS2

Beinhaltet Kompression und eleganten Verschleißschutz.

YAFFS2

  • Einzige Sache, die den Unterschied macht: kurze Mount-Zeiten nach erfolgreichem Umount.
  • Implementiert die Eigenschaft write once: Sobald Daten in einen Block geschrieben wurden, müssen sie nicht mehr neu geschrieben werden. Dies ist wichtig, da es den Verschleiß verringert.

LogFS

  • Nicht sehr ausgereift, aber bereits im Linux-Kernelbaum enthalten.
  • Unterstützt problemlos größere Dateisysteme als JFFS2 / YAFFS2.

UBIFS

  • Ausgereifter als LogFS
  • Schreibe Caching-Unterstützung
  • Zur Skalierbarkeit: Artikel . Auf großen Festplatten bessere Leistung als mit JFFS2

ext4

Wenn kein Treiber oder keine Karte (z. B. SSD-Laufwerke, zumindest in der Regel, über eine interne Abnutzungskorrektur verfügen) die Abnutzungskorrektur übernimmt, ist ext4 nicht die beste Idee, da es nicht für die Verwendung von unformatiertem Flash vorgesehen ist.

Welches ist das beste?

Das hängt natürlich von der Nutzung und dem Support ab. Nach allem, was ich im Internet gelesen habe, würde ich UBIFS empfehlen. Gute Unterstützung für große Dateisysteme, ausgereifte Entwicklungsphase, angemessene Leistung und keine großen Nachteile.


6
Danke, das ist sehr informativ! Die "große rote Notiz" auf der UBIFS-Website lautet jedoch: "Eine Sache, die die Leute beim Umgang mit UBIFS verstehen müssen, ist, dass sich UBIFS von jedem herkömmlichen Dateisystem stark unterscheidet - es funktioniert nicht auf Blockgeräten (wie Festplatten) , MMC / SD-Karten, USB-Flash-Laufwerke, SSDs usw.) UBIFS wurde entwickelt, um auf Raw-Flash zu funktionieren, was nichts mit Blockgeräten zu tun hat. Deshalb funktioniert UBIFS nicht auf MMC-Karten und dergleichen sehen aus wie Blockgeräte für die Außenwelt, weil sie die FTL-Unterstützung (Flash Translation Layer) in Hardware implementieren. "
gspr

3
Schöne Antwort, dazu gibt es F2FS von Samsung, ebenfalls vielversprechendes System, recht neu.
Dienstag,

16
@gspr ist korrekt: SD verfügt über eine Flash-Übersetzungsschicht, und JFFS2, YAFFS2, LOGFS und UBIFS sind alle für nicht verwaltetes Flash konzipiert. Die Optionen für SD sind herkömmliche Dateisysteme für Blockgeräte wie ext2 / ext3 / ext4.
Robert Calhoun

@Olli Ist NILFS2 eine gute Wahl für ein SSD-Laufwerk?
SebMa

12

Ich hatte das gleiche Problem und habe auch einige Nachforschungen angestellt. Schließlich habe ich mich für ext2 entschieden.

Es scheint, dass einige SDHC-Karten auf der Hardware-Ebene einen eigenen Wear-Leveling implementieren. Wenn Sie SDHC-Karten mit eingebautem Wear-Leveling erwerben können.

Dateisysteme, die Wear-Leveling bereitstellen, können das Wear-Leveling auf Flash-Ebene beeinträchtigen, sodass die Verwendung des Flash-Speichers möglicherweise beeinträchtigt wird mit Blitzstufe WL). Ich entschied, dass ich das Journaling von ext3 nicht benötigte, da ich keine kritischen Daten darauf speichere und in der Regel sowieso regelmäßig ein Backup mache (cron).

Ich habe auch / tmp und / var als tmpfs gemountet, um die Dinge zu beschleunigen. Wenn Sie über genügend RAM verfügen, sollten Sie dies tun (achten Sie jedoch darauf, Ihre Protokolle regelmäßig zu drehen oder zu löschen).

TIPP: Hängen Sie Ihre ext SD-Karten mit der Option "noatime" ein


Ich hatte Probleme mit alten SD-Karten und ext2 (Datenkorruption), die beim Umstieg auf XFS wegfielen.
Alexander

1

Ich weiß nicht, ob dies in das Profil Ihres Systems passt, aber was ist mit der Verwendung eines schreibgeschützten Dateisystems plus einer Lese- / Schreibpartition (oder eines USB-Sticks, der leicht ersetzt werden kann)? Auf diese Weise haben Sie eine schnelle Festplatte für Ihr Betriebssystem und können Ihren RW-Speicher problemlos ersetzen, wenn er abgenutzt ist.

Und dann gibt es noch unionfs. So wie ich es verstanden habe, "stapelt" es verschiedene Dateisysteme (dh ein RoFs auf einem RW-Fs). Wenn es einen Lesezugriff gibt, durchsucht unionfs den Stack, bis er die FS mit der gesuchten Datei erreicht. Beim Schreiben sucht unionfs nach dem ersten beschreibbaren FS auf dem Stack und verwendet diesen.

Ich habe auch folgende Artikel gefunden, die interessant sein könnten: http://www.linux-mag.com/id/7357/ http://www.linux-mag.com/id/7345/

Und zwei Artikel mit Tipps zur Verwendung von SSDs: http://danweinreb.org/blog/using-solid-state-disks-on-linux http://www.zdnet.com/blog/perlow/geek-sheet-a- Tweakers-Guide-to-Solid-State-Laufwerke-Ssds-und-Linux / 9190


1
Beachten Sie, dass ich nicht derjenige bin, der diese Antwort abgelehnt hat. Es enthält nützliche Informationen im Allgemeinen, bezieht sich jedoch nicht auf das, was ich benötige.
Trotzdem

0

Die Auswahl (und Dimensionierung) des richtigen Dateisystems ist wichtiger als alles andere, nicht nur aus Sicherheitsgründen, sondern auch aus vielen anderen Gründen, die Menschen normalerweise nicht erkennen. Ohne ein Dateisystem würde die gesamte Verarbeitung auf Null gehen.

Sehr gut formulierte Antwort von Olli, und das OP ist viel veraltet, aber Dateisysteme sind mein Liebling Ich konnte mich nicht fernhalten. superuser.com ist nichts, was ich vorher besucht habe, ich bin kein Administrator, aber ich habe mich angemeldet und werde noch mehr besuchen.

Die Dinge haben sich seit 2011 sehr verändert, aber schon damals habe ich USB-Karten FAT formatiert und USB-Laufwerke verwendet, um 4 GB + -Dateien zu transportieren. Der Grund war natürlich Kompatibilität nicht Sicherheit (so viel für S in SD, aber ich benutze Passwörter für meine 7z), und ich trug nie wirklich etwas Größeres als eine CD ISO, sie waren meistens für SQL-Skripte und täglich stündliche Unterschiede von bereits verschlüsselte Datenbank-Snapshots werden von 7-Zip fast zum Tode gepresst.

In diesen Tagen ziehe ich SD schneller ab als alle anderen, die ich kenne. Ich habe in einigen Produktionsmaschinen meines Arbeitgebers einen USB-Stick für stündlich automatisierte Datensicherungen, die mit FAT formatiert sind. Ich behalte sie jeden Tag im Auge und unterstütze sie - wie Sie vermutet haben - religiös von Hand (sie sind offline gesichert und bauen ITAR-Zeug auf). SSD hat einiges von dem Spielfeld ausgeglichen, aber ich vertraue ihnen immer noch nicht so sehr wie normalem HD und SD ist schlechter als optisch. Sie werden augenblicklich schlecht und der Verlust ist total.

Jedes Dateisystem, das das Host-Betriebssystem zum zufälligen Schreiben auffordert (NTFS, Papierkorb), ist eine schlechte Nachricht für eine SD. Das Abmelden hilft auch sehr, da kein Betriebssystem versucht, auf nicht gemounteten Speicher zuzugreifen. Daher kann jedes Dateisystem verwendet werden, solange die SD ein Skript zum Abmelden enthält (eine der Standarddateien auf jeder SD in meiner).

Das Lesen einer SD ist auch heute noch langsam, daher würde ich so etwas wie Disk Dump (dd) empfehlen, um das gesamte Image beim Spiegeln anstelle von Datei-für-Datei zu erfassen. dd lässt Sie auch wissen, wenn etwas nicht stimmt, damit Ihr Dateimanager nicht kaboomt.

Wenn Ihr primärer Zweck darin besteht, die Lebensdauer einiger Penny Stocks zu verlängern, gehen Sie natürlich falsch mit Ihrem Geschäft um. Ich tue das, was ich tue, nicht, um die Lebensdauer einer SD zu verlängern, sondern um zu verhindern, dass es schlecht wird, wenn ich nicht gucke, und da ist der Unterschied.

Ich vermeide ext4 oder jedes Journaling von FS auf SD, weil es mir egal ist, wenn sie schlecht geschrieben werden, aber es tut sicher weh, wenn ich sie einen Tag oder so später nicht lesen kann!


2
Sorry, aber das beantwortet die Frage nicht wirklich. Es ist ein interessanter Aufsatz über die Verwendung von Wechselmedien, aber nicht über die Wahl des Dateisystems.
Verdächtiger

Ich wollte einen Kommentar abgeben, konnte es aber nicht. Der Beitrag ist ein bisschen ausführlich. Was ich empfohlen habe, war, dass weder das OP darüber nachdachte, sondern dass ich stattdessen FAT empfahl. Ich hätte sicher mit mehr Fokus und Klarheit komponieren sollen.
Arch-Abit

Warum ist Any file system which invites the host OS to write randomly to it (NTFS, Recycle Bin) is bad news for an SD.? Es besteht nicht aus rotierenden Scheiben, also denke ich, wo immer Sie lesen / schreiben sollten, sollte das keine Rolle spielen. Und übrigens schreibt NTFS fortlaufend - was zur Fragmentierung führt. Bei «Random Stores of Files» handelt es sich zB um EXTα.
Hi-Angel

0

Als Reaktion auf die Empfehlung zur Verwendung von Fat (32?): Ich habe einige Leistungstests durchgeführt und festgestellt, dass Fat32 eine sehr vorhersehbare Zeit zum Schreiben einer Datei hat (2 GB benötigen das Zweifache von 1 GB + Offset, 3 GB das Dreifache von 1 GB + Versatz). Die Leistung von ext4 ist etwas besser als die von ext3. Sowohl ext3 als auch ext4 sind manchmal schnell, benötigen jedoch manchmal etwas mehr Zeit, um die Journaldateien auf die Festplatte zu schreiben (kein lineares Schreibzeitverhalten). Alle Tests wurden mit fsync () durchgeführt, um sicherzustellen, dass die Datei wirklich auf die Festplatte geschrieben wurde. Ich habe einige Tests mit sync () durchgeführt. Sie führen zu einer sehr schlechten Schreibleistung. Also bin ich zurück zu fsync () gegangen. Ich habe ein bisschen nachgesehen, ob fsync () ausreicht. Deshalb habe ich das Gerät ausgeschaltet, ohne das System herunterzufahren, oder die SD-Karte entfernt, ohne die Verbindung zu trennen. In keinem Fall wurden die geschriebenen Dateien oder die Verzeichnisstruktur beschädigt.

Grüße, Thomas


1
Der Vergleich ist unfair. Sie haben FAT ohne Journaling mit EXT3 / 4 verglichen. Sie sollten FAT mit EXT2 vergleichen. Und nur zu Ihrer Information, das vom Hersteller vorformatierte Dateisystem hat normalerweise die optimalsten Blockgrößen / Offsets. Dh nach der Neuformatierung des Dateisystems besteht die Möglichkeit, dass die Eingabe länger dauert als bei der ursprünglichen.
Hi-Angel

0

wenn du verlustfreie sd karte willst schlage ich vor mit BTRFSweil:

BTRFS ist ein neues Dateisystem im Vergleich zu EXT, das ursprünglich 2007 von Oracle erstellt wurde.

Es bringt neue Funktionen in traditionelle Dateisysteme:

  • Klonen / Schnappschüsse
  • Diffs (senden / empfangen)
  • Quotat
  • Union
  • Selbstheilung (mit Festschreibungsperioden von standardmäßig 30 Sekunden)

Weitere Erläuterungen und Vergleiche finden Sie in diesem PDF

Weitere Vergleiche finden Sie auf dieser Website

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.