Ich habe eine SDXC Karte mit 128GB Speicher gekauft, und ich will diese
so mit EXT4 formatieren, dass die Performance nicht leidet, die
Lebensdauer der SD-Karte nicht beeinträchtigt wird, und auch was auch
immer noch so für hacks in dieser SD-Karte sind die Datenintegrität
nicht beeinträchtigt.
Ich habe schonmal ein Backup der ersten 512MiB der neuen und auch
unbenutzten SD Kate erstellt. Ich möchte diese SD Karte später in meinem
Ubuntu Phone nutzen, sobald dieses ankommt. Ich würde gern wissen, wie
der optimale Formatierbefehl unter Linux unter Berücksichtigung von
Dingen wie Blockgrösse etc. aussehen sollte. Ausserdem zeigt mir gdisk
wenn ich die Partitionstabelle ausgebe die Warnung "Warning! Secondary
partition table overlaps the last partition by
33 blocks!" an, bedeutet dies, dass ich die Partition um 4 Sektoren
verkleinern sollte? Kann ich riskieren dies mit einem Tool wie fdisk
oder gdisk zu machen, oder sollte ich einen Hexeditor verwenden?
Hier ist noch die Ausgabe von gdisk:
1
daniel@Daniels-Surface-Pro-3:~$ gdisk -l /dev/sdb
2
GPT fdisk (gdisk) version 1.0.1
3
4
Problem opening /dev/sdb for reading! Error is 13.
Für meine SSDs habe ich parted verwendet:
# parted --align optimal /dev/xyz
> optimal Use optimum alignment as given by the disk topology information.> This aligns to a multiple of the physical block size in a way that guarantees> optimal performance.
Für die gesamte Karte dann mkpart .. 0% 100%, alles weitere sucht sich
parted dann passend zusammen.
Deine Fehlermeldung habe ich noch nie gesehen. Liegt das vielleicht an
der Umwandlung vom MBR Format? Mit MBR gibt es keine zweite Tabelle am
Ende, bzw. nichts was überlappt werden könnte.
Daniel A. schrieb:> und ich will diese so mit EXT4 formatieren, dass die Performance nicht> leidet, die Lebensdauer der SD-Karte nicht beeinträchtigt wird,
Das ist ein Widerspruch in sich. Der SD Standard schreibt vor, dass du
bei exFAT verwenden musst, damit der Controller in der Karte erkennt
welche Blöcke besetzt sind und damit das Wear Leveling umsetzen kann.
Tr schrieb:> Mit MBR gibt es keine zweite Tabelle am Ende, bzw. nichts was überlappt> werden könnte.
In dem fall kann ich davon ausgehen, dass die Partitionstabelle bereits
optimal ist, demzufolge müsste ich dort ja nur den code des
Partitionstypes ändern.
Dann muss ich die Partition aber immernoch formatieren.
Dr. Sommer schrieb:> Der SD Standard schreibt vor, dass du bei exFAT verwenden musst, damit> der Controller in der Karte erkennt welche Blöcke besetzt sind und damit> das Wear Leveling umsetzen kann.
Ich frag mich wie MS das wieder durchsetzen konnte...
Wo kann ich mir diesen Standard besorgen, wear Leveling auf basis des
Dateisystems muss extrem unzuverlässig sein, ich kann kaum glauben das
soetwas in einem Standard stehen soll. Unterstützen SDXC karten von
SanDisk eigentlich das trim kommando? Vermutlich werde ich wohl direkt
bei SanDisk nachfragen müssen, wie sich deren Wear Leveling unter den
Umständen verhalten würde.
Daniel A. schrieb:> Wo kann ich mir diesen Standard besorgen,
sdcard.org, ist aber teuer.
Daniel A. schrieb:> wear Leveling auf basis des Dateisystems muss extrem unzuverlässig sein
Warum? Wenn der Controller anhand der Dateisystem Strukturen (Die FAT
bei klassischem FAT16/32 , vorgeschrieben für SDSC/SDHC) erkennen kanns
welche Blöcke unbenutzt sind, kann er sie wieder verwenden.
Dass SD Karten aber nicht auf Zuverlässigkeit ausgelegt sind und das
ganze System eine ziemliche Bastelei ist, sollte ja klar sein. Für
"Qualität" nimmt man CF.
Daniel A. schrieb:> Unterstützen SDXC karten von SanDisk eigentlich das trim kommando?
Das trim Kommando ist ATA spezifisch, das gibt's bei SD Karten nicht.
Daher ist es ja erforderlich, das richtige Dateisystem zu verwenden,
damit der Controller die freien Blöcke richtig erkennt.
Daniel A. schrieb:> Vermutlich werde ich wohl direkt bei SanDisk nachfragen müssen, wie sich> deren Wear Leveling unter den Umständen verhalten würde.
Wenn du auf dem Wege was heraus findest, poste doch mal das Ergebnis,
das würde mich auch interessieren.
PS: Ohne Werbung machen zu wollen, ich habe mal die Performance von
einigen Karten verglichen, und SanDisk war am schlechtesten, und Samsung
mit Abstand am schnellsten. Das Wear Leveling habe ich allerdings nicht
untersucht.
Dr. Sommer schrieb:> Das trim Kommando ist ATA spezifisch, das gibt's bei SD Karten nicht.
Doch manche SD-Karten können sowas, wenn der SD-Karten Leser dies
unterstützt (Wie bei vielen SBCs). "fstrim /" funktioniert bei mir bei
einer von 3 MicroSD Karten an einem PCDuino.
Lukas S. schrieb:> Doch manche SD-Karten können sowas,
Interessant, wie funktioniert das? In der SD-Spezifikation wird kein
Wörtchen über einen "Trim"-Befehl verloren. Gibt es da einen geheimen
Zusatz-Standard, den nur der PCDuino kennt? Woher weißt du dass es
"funktioniert" und dort tatsächlich ein mysteriöser Befehl an die Karte
gesendet wird, und nicht einfach nur ein "Erase" o.ä. durchgeführt?
Dr. Sommer schrieb:> Daniel A. schrieb:>> und ich will diese so mit EXT4 formatieren, dass die Performance nicht>> leidet, die Lebensdauer der SD-Karte nicht beeinträchtigt wird,>> Das ist ein Widerspruch in sich. Der SD Standard schreibt vor, dass du> bei exFAT verwenden musst, damit der Controller in der Karte erkennt> welche Blöcke besetzt sind und damit das Wear Leveling umsetzen kann.
Das kommt mir alles sehr komisch vor, was Dr. Sommer da erzählt!
Wear Leveling
=============
Wear Leveling benötigt meinem Verständnis nach überhaupt keine
Informationen darüber, welche Sektoren oder Cluster eines Datenträgers
genutzt werden oder nicht.
Für Wear Leveling muss irgendwo die Anzahl der Schreibzugriffe pro Block
gezählt werden.
Bei Erreichen einer Grenze muss der Block kopiert werden. Die Quelle
muss stillgelegt werden und alle weiteren Zugriffe werden auf den neuen
Block umgeleitet.
Ein solcher Vorgang läuft vollkommen unabhängig von der Nutzung dieser
Blöcke durch das Betriebssystem ab.
Trimmen
=======
Trimmen ist nach meinem Verständnis etwas anderes. Trimmen bedeutet
explizites Im-Voraus-Löschen von ungenützten Blöcken, um Schreibzugriffe
darauf zu beschleunigen.
Dafür muss das Betriebssystem dem Controller die ungenutzten Blöcke
anzeigen.
Wenn der Controller ohne Betriebssystemhilfe trimmen wollte, müsste er
selbstständig Partitions- und Dateisystemstrukturen interpretieren.
Spätestens bei einer verschlüsselten Platte sieht er aber gar nichts
mehr.
=> Bitte an Dr.Sommer: Quelle für das unterstellte Verhalten zeigen!
Peter M. schrieb:> und alle weiteren Zugriffe werden auf den neuen> Block umgeleitet.
Richtig. Und wo kommt der neue Block her? Genau, es wird ein unbenutzter
Block des Mediums genommen. Woher weiß der Controller welche Blöcke
unbenutzt sind?
(S)ATA-SSD's: TRIM-Befehl.
SD-Karten: Dateisystem-Strukturen (FAT).
Peter M. schrieb:> Ein solcher Vorgang läuft vollkommen unabhängig von der Nutzung dieser> Blöcke durch das Betriebssystem ab.
Nein, denn das Medium muss wissen welche Blöcke als Ersatz für
erschöpfte Blöcke herhalten können.
Peter M. schrieb:> Trimmen bedeutet> explizites Im-Voraus-Löschen von ungenützten Blöcken, um Schreibzugriffe> darauf zu beschleunigen.
Nach DEM Verständnis können SD-Karten das, die haben einen Erase-Befehl.
Das Verständnis ist aber falsch, denn laut Wikipedia:
Durch den ATA-Befehl TRIM wird dem Laufwerk beim Löschen von Dateien
mitgeteilt, dass es die davon betroffenen Blöcke als ungültig markieren
kann, anstelle deren Daten weiter vorzuhalten. Die Inhalte werden nicht
mehr weiter mitgeschrieben, wodurch die Schreibzugriffe auf das Laufwerk
beschleunigt und zudem die Abnutzungseffekte verringert werden. Die
ungültig markierten Blöcke werden dann beim nächsten Löschen ihres
Erasable Blocks frei.
Der Lösch-Befehl von SD-Karten löscht aber sofort, ist somit verschieden
- insbesondere langsamer - als der ATA-TRIM-Befehl. Erase als Ersatz für
TRIM zu nutzen könnte bei schlauen SD-Karten effizient sein auch in
Kombination mit einem nicht-standardisierten Dateisystem - aber das ist
von der SD-Spezifikation absolut nicht garantiert.
Peter M. schrieb:> Wenn der Controller ohne Betriebssystemhilfe trimmen wollte, müsste er> selbstständig Partitions- und Dateisystemstrukturen interpretieren.
Genau das tuen SD-Karten.
Peter M. schrieb:> Spätestens bei einer verschlüsselten Platte sieht er aber gar nichts> mehr.
Deswegen wird Partitions-Verschlüsselung bei SD-Karte nicht unterstützt.
Peter M. schrieb:> => Bitte an Dr.Sommer: Quelle für das unterstellte Verhalten zeigen!
1. SD Specifications - Part 1 Physical Layer Simplified Specification
enthält absolut nichts über einen Trim-Befehl oder dergleichen,
lediglich den genannten Erase-Befehl. Man kann(!) der SD-Karte überhaupt
nicht sagen, welche Blöcke man nicht mehr braucht - sie muss es folglich
aus den Dateisystem-Strukturen lesen.
2. SD Specifications - Part 2 File System Specification"
Beschreibt FAT16/32/exFAT sowie das genaue Layout der Partition. Nichts
von ext4. Ergo ist nur die jeweilige FAT-Variante unterstützt, und auch
nur bei genau einem bestimmten Partitions-Layout.
Das Wear Leveling einer Karte von außen zu beurteilen ist leider
schwierig, aber man kann ersatzweise die Dauer von
Schreib/Lösch-Operationen auf der Karte messen bei einem Langzeit-Test.
Man erhält komplexe Muster (anders als bei einem "dummen" Flash-IC) die
darauf hindeuten, dass im Controller Algorithmen z.B. für Zwecke des
Wear-Leveling ablaufen. Diese benötigen wie erläutert die Informationen
des Dateisystems.
Siehe z.B. auch hier:
https://www.sdcard.org/downloads/formatter_4/index.html
"The SD Formatter was created specifically for memory cards using the
SD/SDHC/SDXC standards. It is strongly recommended to use the SD
Formatter instead of formatting utilities provided with operating
systems that format various types of storage media. Using generic
formatting utilities may result in less than optimal performance for
your memory cards."
Man soll sogar nichtmal das Windows-eigene Formatierungstool für FAT
nutzen, da dies die Partition von Haus aus nicht an die richtige Stelle
packt, an der der SD-Karten-Controller sie erwartet.
Natürlich kann es sein dass einzelne Karten auch mit ext4 gut
funktionieren. Das ist aber vom Standard nicht garantiert, und da ich
wie erwähnt SanDisk Karten als nicht besonders hochwertig einschätze,
halte ich es für unwahrscheinlich dass das bei denen der Fall ist.
Dr. Sommer schrieb:> Peter M. schrieb:>> und alle weiteren Zugriffe werden auf den neuen>> Block umgeleitet.> Richtig. Und wo kommt der neue Block her?> Genau, es wird ein unbenutzter> Block des Mediums genommen. Woher weiß der Controller welche Blöcke> unbenutzt sind?> (S)ATA-SSD's: TRIM-Befehl.> SD-Karten: Dateisystem-Strukturen (FAT).
Ich unterstelle, Ersatzblöcke für das Wear-Leveling kommen aus einem
Reservepool, genauso wie "Reallocated Sectors" bei einer Festplatte.
Ansonsten würde jeder verschliessene Block die Gesamtkapazität des
Datenträgers um den Speicherplatz des Block vermindern.
Was Du in diesem Textabschnitt schreibst, kommt mir wieder nicht
plausibel vor.
> Nach DEM Verständnis können SD-Karten das, die haben einen Erase-Befehl.> Das Verständnis ist aber falsch, denn laut Wikipedia:>> Durch den ATA-Befehl TRIM wird dem Laufwerk beim Löschen von Dateien> mitgeteilt, dass es die davon betroffenen Blöcke als ungültig markieren> kann, anstelle deren Daten weiter vorzuhalten. Die Inhalte werden nicht> mehr weiter mitgeschrieben, wodurch die Schreibzugriffe auf das Laufwerk> beschleunigt und zudem die Abnutzungseffekte verringert werden. Die> ungültig markierten Blöcke werden dann beim nächsten Löschen ihres> Erasable Blocks frei.
Hier steht anscheinend Unsinn in der Wikipedia!
Am besten die ganze SD-Karte mit einem Schreibschutz versehen, weil dann
"die Schreibzugriffe auf das Laufwerk beschleunigt und zudem die
Abnutzungseffekte verringert werden" ???
Ich unterstelle:
Auch SD-Karten können als Block-Device angesprochen werden.
Jeder Sektor muss immer beschreibbar bleiben.
Der TRIM-Befehl bewirkt, dass der Block als löschbar markiert wird und
bei der nächsten Gelegenheit vom Controller physisch gelöscht wird.
Folgt auf einen TRIM-Befehl ein Schreibbefehl auf einen vom TRIM-Befehl
betroffenen Block, muss der entweder aus dem löschbaren Pool wieder
entnommen werden oder auf einen anderen hoffentlich gelöschten Block
umgeroutet werden.
Ansonsten danke für die Links!
Dr. Sommer schrieb:> Natürlich kann es sein dass einzelne Karten auch mit ext4 gut> funktionieren. Das ist aber vom Standard nicht garantiert, und da ich
Hi,
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ext4.txt
discard Controls whether ext4 should issue discard/TRIM
nodiscard(*) commands to the underlying block device when
blocks are freed. This is useful for SSD devices
and sparse/thinly-provisioned LUNs, but it is off
by default until sufficient testing has been done.
Also einfach einschalten zu Fuss eg. tune2fs -o discard /dev/sdX
oder halt beim mounten.
Zusaetlich halt halt timestamping abschalten, noatime.
Mir bekannte die auch damit umgehen koennen Btrfs,XFS,JFS evtl.
mittlerweile aber noch weitere?
--
Sollte gehen, auf zum 'sufficient testing' ...
no risk, no fun :)
Peter M. schrieb:> Ich unterstelle, Ersatzblöcke für das Wear-Leveling kommen aus einem> Reservepool, genauso wie "Reallocated Sectors" bei einer Festplatte.
Nun, wenn man das zugrunde legt ist es natürlich sinnlos dass die
SD-Spezifikation ein Dateisystem vorschreibt. Da fragt man sich, warum
sie das getan haben?
> Ansonsten würde jeder verschliessene Block die Gesamtkapazität des> Datenträgers um den Speicherplatz des Block vermindern.
Ich würde eher sagen, sobald ein Block der Karte defekt ist, ist die
ganze Karte defekt. Da aber durch das Wear Leveling die Abnutzung auf
alle Blocks gleichmäßig verteilt wird, passiert das erst wenn alle
Blöcke kurz vor dem Defekt sind.
Peter M. schrieb:> Hier steht anscheinend Unsinn in der Wikipedia!
Nun das kann sein, ich kenne mich mit ATA und TRIM nicht so gut aus. Ist
auch egal hier, denn SD-Karten kennen kein TRIM.
Peter M. schrieb:> Ich unterstelle:> Auch SD-Karten können als Block-Device angesprochen werden.
Quelle?
> Jeder Sektor muss immer beschreibbar bleiben.
Quelle? Die SD-Spezifikation sieht das so jedenfalls nicht vor.
+/- schrieb:> Also einfach einschalten zu Fuss eg. tune2fs -o discard /dev/sdX> oder halt beim mounten.
Ja ich weiß, das mach ich bei meinen SSD's auch. Es geht aber nicht um
SSD's, sondern um SD-Karten, und die haben kein TRIM! Der TRIM-Befehl
muss irgendwie an die Karte gehen, aber die Karten verstehen keinen
derartigen Befehl! Davon kannst du dich gerne überzeugen:
https://www.sdcard.org/downloads/pls/pdf/part1_410.pdf
S. 69 - 76 ist die Liste der Befehle. Da steht nix von TRIM.
Dr. Sommer schrieb:> Peter M. schrieb:>> Ich unterstelle:>> Auch SD-Karten können als Block-Device angesprochen werden.> Quelle?>> Jeder Sektor muss immer beschreibbar bleiben.> Quelle? Die SD-Spezifikation sieht das so jedenfalls nicht vor.
Ohne Zugriff als Block-Device könnten Formatierprogramme nicht
partitionieren und formatieren.
Ich weiß nicht, ob das so in irgendeiner Spezifikation drinsteht, das
ist so elementar.
Gerade habe ich auf meiner 32GB-SD-Karte den letzten Sektor mit dem
Diskeditor verändert.
Ohne Blockzugriff wäre das nicht möglich.
Peter M. schrieb:> Ohne Blockzugriff wäre das nicht möglich.
Ja, es gibt den Blockzugriff. Aber falls sich der Controller
entscheidet, den Block als Ersatz für einen anderen zu verwenden weil er
noch als frei gilt (weil in der FAT so markiert), wird der Inhalt
verändert... Das ist bei einem "dummen" Block-Device nicht der Fall.
Ich kann es kaum glauben.
Das würde bedeuten, dass der Inhalt von Sektoren bei SD-Karten, die
SD-standardkompatibel mit FAT formatiert sind, nicht mehr definiert
sind, weil sie sich ändern können. ???
Es lebe das gemeine, dumme Block-Device, da werden nicht einfach
Sektoren verändert.
Peter M. schrieb:> Das würde bedeuten, dass der Inhalt von Sektoren bei SD-Karten, die> SD-standardkompatibel mit FAT formatiert sind, nicht mehr definiert> sind, weil sie sich ändern können. ???
Sofern sie nicht zu einer Datei gehören, kann das passieren.
Peter M. schrieb:> Es lebe das gemeine, dumme Block-Device, da werden nicht einfach> Sektoren verändert.
Dumme Block-Devices machen halt kein Wear-Leveling und kriegt man nicht
für 10€ bei Aldi.
Das ganze ist ja überhaupt kein Problem, wenn man die Karte
standardkonform, d.h. mit dem vorgeschriebenen FAT16/32/exFAT nutzt. Die
meisten Karten sind vermutlich so programmiert, dass sie, falls kein FAT
drauf ist, sich "dumm" stellen und alle Zugriff 1:1 durchleiten. Dann
ist aber das Wear Leveling abgeschaltet.
Die verlinkten "Simplified Specifications" von sdcard.org sind
unvollständig, für die Vollständigen müsste man Mitglied sein, und dafür
verlangen die 2'000$ ?!?
Wie auch immer, in "Part 1 Simplified Physical Layer Simplified
Specification" steht:
> 4.13.2.7.3 Requirements of SD File System>> This specification can be applied only to the SD file system formatted> card defined by the File System Specification Version 3.00. This includes> complying with the format par ameter calculation specified in the Appendix> C of the File System Specification Version 3.00. Furthermore, the Number> of Hidden Sectors shall be adopted as minimum number that meets Boundary> Unit Recommendation for Data Area. And in case of exFAT file system,> Allocation Bitmap shall be stored in the first 4MB of Cluster Heap.
Die "File System Specification Version 3.00" scheint wohl nur
Mitgliedern zugänglich zu sein, und in "Part 1 Simplified Physical Layer
Simplified Specification" schreibt nirgends explizit vor, dass exFAT
verwendet werden muss, geht aber bei SDXC Karten davon aus. Ausserdem
wird eine "FAT Update sequence" festgelegt, in welcher Reihenfolge was
und wie auf die SDXC geschrieben werden soll. Andererseits wird Wear
Leveling in dem Dokument nicht erwähnt. Dennoch könnten einige
Hersteller sich durchaus auf ein exFAT für Wear Leveling verlassen, da
Dinge wie die "FAT Update sequence" der Karte eine Grundlage liefern, um
das exFAT Dateisystem on-the-fly interpretieren zu können. Natürlich
wäre der ERASE Befehl für das freigeben von Blöcken, und somit als TRIM
Kommando vollkommen ausreichend, da auch definiert wurde welchen Inhalt
die gelöschten Felder danach enthalten, und eine Markierung der Bereiche
damit theoretisch möglich wäre.
Ich finde es unglaublich, das ein derart verbreiteter Standard für einen
simplen Datenträger ein Dateisystem derart in sich verankern kann. Im
grunde genommen interpretiere ich das so, das man sich nach jeder Art
von Änderung an der Partitionstabelle oder dem Dateisystem der SD Karte
nichtmehr darauf verlassen kann, dass diese weiterhin funktionieren.
Meine Schlussfolgerung ist daher, das nur SanDisk mir sagen kann, ob
ihre Karten mit EXT4 klarkommen und falls ja, welche Parameter das EXT4
Dateisystem haben muss.
Ich glaube ich nicht das die Karte die FAT beachtet. Ich wüsste auch
nicht wie man das sicher implementieren könnte.
Es steht ja gar nicht die Reihenfolge fest, wenn das FAT neu geschrieben
wird.
Wenn eine neue Datei angelegt wird, werden die Sektoren schon
beschrieben und in der FAT steht im dem Moment noch das sie frei sind -
dafür dürfte die Karte die Daten einfach löschen - kann ja wohl nicht
sein.
Wenn man zuerst die FAT beschreibt, würde das Problem weg sein - dafür
wird die FAT viel zu oft neu geschrieben - was man auf einer SD-Karte
auch nicht will.
> Das ganze ist ja überhaupt kein Problem, wenn man die Karte> standardkonform, d.h. mit dem vorgeschriebenen FAT16/32/exFAT nutzt.
Dann erklaere doch mal was ein Standkonformes FATxy Format ist. Also vor
dem Hintergrund das es gerade bei FAT auch die unterschiedlichsten
denkbaren formatierungen gibt. (Superfloppy/partioniert,
unterschiedliche Clustergroessen, Anzahl und position der FAT)
Ich glaub deshalb auch nicht das es das gibt von dem du da traeumst weil
so eine Karte dann ziemlich intelligent sein muesste.
Olaf
Olaf schrieb:> Dann erklaere doch mal was ein Standkonformes FATxy Format ist.
Wie bereits erläutert, genau das was in der "SD Specifications Part 2
File System Specification" steht.
Olaf schrieb:> Also vor> dem Hintergrund das es gerade bei FAT auch die unterschiedlichsten> denkbaren formatierungen gibt. (Superfloppy/partioniert,> unterschiedliche Clustergroessen, Anzahl und position der FAT)
Daher ist in der o.g. Spezifikation ganz genau festgelegt, wie das
auszusehen hat. Daher darf man SD-Karten nicht irgendwie mit FAT
formatieren. Daher gibt es das o.g. Formatter Tool auf sdcard.org.
Olaf schrieb:> Ich glaub deshalb auch nicht das es das gibt von dem du da traeumst
Wenn du denkst ich hätte die SD-Sepzifikation nur geträumt, kannst du
sie ja kaufen und hereinschauen.
Olaf schrieb:> weil> so eine Karte dann ziemlich intelligent sein muesste.
Ganz genau das ist die Aussage. Der Controller in der Karte ist
ziemlich intelligent. Warum sonst hat der so viel Programm-Speicher?
Siehe z.B. http://www.bunniestudios.com/blog/?p=918 :
"... by making the controllers very smart (the Samsung controller is a
32-bit ARM7TDMI with 128k of code ..."
Peter II schrieb:> Ich glaube ich nicht das die Karte die FAT beachtet.
Warum schreiben die Leute hier immer nur was sie glauben? Ist das hier
fröhliches Rätselraten? In der SD-Spezifikation steht ganz klar dass die
FAT spezielle Beachtung erfährt, und das Dateisystem ist nicht aus Spaß
so genau vorgeschrieben.
Dr. Sommer schrieb:> Peter II schrieb:>> Ich glaube ich nicht das die Karte die FAT beachtet.>> Warum schreiben die Leute hier immer nur was sie glauben? Ist das hier> fröhliches Rätselraten? In der SD-Spezifikation steht ganz klar dass die> FAT spezielle Beachtung erfährt, und das Dateisystem ist nicht aus Spaß> so genau vorgeschrieben.
es steht aber nicht drin, was sie mit dem Wissen über die FAT macht.
Ich habe auch geschrieben, warum ich das nicht glaube. Was hast du dazu
zu sagen, wenn es ja scheinbar genau weist?
Nachtrag:
Ich könnte mir vorstellen, das die Sektoren die die FAT enthalten anders
gebaut sind oder in einem andere Bereich der Karte liegen weil sie
öfters beschrieben werden.
Dr. Sommer schrieb:> "... by making the controllers very smart (the Samsung controller is a> 32-bit ARM7TDMI with 128k of code ..."
Andrew schreibt ein Paar Zeilen tiefer aber auch:
(...) I love the fact that (...)I can be completely oblivious to the
existence of bad blocks and use mature filesystems like ext3 (...)
Mit anderen Worten: Er sieht keine Probleme darin, andere Filesysteme zu
verwenden.
"Der SD Standard schreibt vor, dass du bei exFAT verwenden musst, damit
der Controller in der Karte erkennt welche Blöcke besetzt sind und damit
das Wear Leveling umsetzen kann."
Das steht so im Bezug zu Wear Leveling nirgendswo so in der
Spezifikation. Für den Controller ist das File System egal, bei
Low-Level-Zugriffen ohne File System wird nichts überschrieben. Die Wahl
des File Systems stand auch nie im Zusammenhang mit dem Controller,
exFAT wird aufgrund der nachteiligen Directory-Struktur bei FAT32
verwendet. Der Formatter von SD Org wird deshalb empfohlen, weil FAT von
MS und von SD sich etwas unterscheiden und wenn die Hardware
SD-ORG-spezifisch arbeitet kann sie uU. Karten, die mit Win formattiert
sind, nicht lesen. Ferner kann Win die "Procted Area" beim formatieren
löschen, da diese in den Spezs fehlt.
Ich habe gerade eine E-Mail vom SanDisk Support bekommen. Das Wear
Leveling von SanDisk USB-Sticks und Speicherkarten ist vom Dateisystem
unabhängig. Die SD Karte sollte mit ext4 weiterhin fehlerfrei
funktionieren und die Leistung und Lebensdauer sollten nicht
beeinträchtigt werden. Für die Formatierung mit ext4 empfehlen Sie mir
für Dinge wie die Blockgrösse die Default-optionen zu verwenden.
Daniel A. schrieb:> Das Wear> Leveling von SanDisk USB-Sticks und Speicherkarten ist vom Dateisystem> unabhängig.
Was anderes wäre ja auch irgendwie unlogisch gewesen.
Warum installiere ich ein Journaling-Filesystem wenn ich das Journaling
deaktivieren will? Warum installiere ich Ext4, welches zwar Trim kann,
jedoch meine SD-Karte Trim nicht kennt? Warum nutze ich nicht den
Standart-Format des Endgerätes (wird wohl vFAT sein)? Warum denke ich
über einige Hundertstelsekunden der Performance eines Dateisystems nach
wenn es zig weitere Faktoren (Kartentyp, Controller, Datenbus,
Prozessor, usw.) gibt, die weit mehr ausbremsen können? Fragen über
Fragen?
rosch schrieb:> Warum installiere ich ein Journaling-Filesystem wenn ich das Journaling> deaktivieren will?
Warum du das machst weiss ich nicht, ich lasse Journaling an. Ich habe
darüber nachgedacht, ext2 zu verwenden, aber mich dagegen entschieden.
Ich habe nicht vor unmengen kleiner Dateien auf die SD zu schreiben,
oder überhaupt haufig Dateien darauf zu speichern. Somit sind die
Performanceeinbussen und zusätzlichen Dateisystemoperationen beim
schreiben von Daten für mich irrelevant.
> Warum installiere ich Ext4, welches zwar Trim kann,> jedoch meine SD-Karte Trim nicht kennt?
Und wo liegt da das Problem? Ausserdem wissen wir doch garnicht, was der
Kernel bei SD Karten macht, wenn trim aktiv ist. Es könnte durchaus
sein, das das einfach die unbenutzten blöcke löscht, und das könnte
sogar von vorteil sein.
Nebenbei, welches OS nutzt du denn, bei welchem du ext4 support erst
nachinstallieren musst, und warum installierst du Dateisysteme, die du
nicht verwenden willst? Es gibt schon merkwürdige Leute...
> Warum nutze ich nicht den Standart-Format des Endgerätes (wird wohl vFAT sein)?
Standard bei SDXC karten ist exFAT, ein quasistandart von Microsoft (ich
mag MS "Standards" und Programme nicht) welches vom MS noch mit Patenten
gespickt wurde, kein Berechtigungskonzept hat, etc.
Mein Endgerät ist ein Ubuntu Phone, welches die Linux Distribution
Ubuntu Touch beinhaltet. Dateisysteme wie FAT sind bei Unixoiden
Systemen eher unvorteilhaft. Die ext* Dateisysteme hingegen sind bei
linux nicht unüblich, haben keine der FAT limitationen, sind nicht von
MS, sind zuverlässiger, und wenn es auf alten 80GB Festplatten schon
sinn machte, dann auch auf einer 128GB SDXC Karte.
Dinge wie ZFS wären aber schon etwas overkill gewesen, aber vielleicht
verschlüssle ich es ja mal mit luks, falls ich mal irgendwetwas finde
das sonst keiner sehen soll...
> Warum denke ich über einige Hundertstelsekunden der Performance eines
Dateisystems nach wenn es zig weitere Faktoren (Kartentyp, Controller, Datenbus,
Prozessor, usw.) gibt, die weit mehr ausbremsen können?
Ja, warum denkst du darüber nach? Mir geht es um all die anderen
Vorteile, sonst hätte ich mir einfach das schnellere Kartenmodell
besorgt.
> Fragen über Fragen?
Da Fragt man sich schon.
PS: i/o? i=o!
"Ausserdem wissen wir doch garnicht, was der
Kernel bei SD Karten macht, wenn trim aktiv ist. Es könnte durchaus
sein, das das einfach die unbenutzten Blöcke löscht, und das könnte
sogar von vorteil sein."
Das File System ist vom Kernel der SD Karte völlig unabhängig,
unbenutzte Blöcke werden nicht gelöscht. Der Karte ist es egal ob da
eines der FATs, NTFS, exts oder was auch immer drauf ist. Die
Performence der Karte wird sich allerdings je nach verwendetem File
System ändern. Trim ist im Kernel NICHT implementiert, es ist aber
durchaus möglich (und auch relativ einfach) dies in der Implementierung
des File Systems nachzurüsten. Jede Karte seit der ersten Specs
ermöglicht Blöcke zu löschen (CMD32), wenn also die ext4 Implementation
auf Linux trim für SD Karten unterstützt, wird dies ohne weiteres
funktionieren.
Norbert T. schrieb:> "Ausserdem wissen wir doch garnicht, was der> Kernel bei SD Karten macht, wenn trim aktiv ist. Es könnte durchaus> sein, das das einfach die unbenutzten Blöcke löscht, und das könnte> sogar von vorteil sein.">> Das File System ist vom Kernel der SD Karte völlig unabhängig
Die SD Karte hat keinen Kernel, sondern eine Firmware. Ich beziehe mich
somit auf die Implementation im Linux Kernel.
Die Firmware der SD Karte ist einer Art kleines Betriebssystem, aber
egal... du kannst doch relativ einfach überprüfen, wie ext4 in dem Fall
funktioniert: schreibe eine Datei auf die Karte, finde dann die
entsprechenden Blocks auf der Karte, lösche die Datei und schaue dann
noch mal ob die Datei immer noch da ist oder ob die Blocks überschrieben
worden sind. Bei FAT ist das nicht der Fall - alles ist da.
Daniel A. schrieb:> unbenutzten SD Kate erstellt. Ich möchte diese SD Karte später in meinem> Ubuntu Phone nutzen, sobald dieses ankommt. Ich würde gern wissen, wie
Hi, wird das eigentlich ldgl. ein Datenspeicher oder ein
'Systemlaufwerk'?
Linuxtypisches loggen, auslagern, Umgang mit temporaerem etc., egal wie
der Speicher konkret verwaltet wird, je weniger man ihn beschaeftigt um
so laenger wird er nunmal halten und funktionieren.
speziell zu ext4 findet sich hier eine kurzfassung,
http://www.haydenjames.io/increase-performance-lifespan-ssds-sd-cards/
Hatte anfangs nur quer gelesen. Ein -o discard wird dsbzgl. nichts
bringen, ist jetzt aber auch nicht weiter tragisch. Was sagt denn
eigentlich ein hdparm zu dem Teil, welche Infos gibt das Preis?
---
Das ist auch recht interessant und scheint halbwegs aktuell,
Filesystem considerations for embedded devices
http://events.linuxfoundation.org/sites/events/files/slides/fs-for-embedded-full_0.pdf
---
Norbert T. schrieb:> schreibe eine Datei auf die Karte, finde dann die> entsprechenden Blocks auf der Karte, lösche die Datei und schaue dann> noch mal ob die Datei immer noch da ist oder ob die Blocks überschrieben> worden sind.
Habe ich eben ausprobiert, allerdings auf 2 PCs, weil das Ubuntu Phone
noch nicht angekommen ist. Die Daten waren nach dem Löschen immernoch
vollständig vorhanden. Ich habe auch fstrim versucht, welches mir sagt,
das das bei der Karte nicht unterstützt wird.
+/- schrieb:> Hi, wird das eigentlich ldgl. ein Datenspeicher oder ein> 'Systemlaufwerk'?
Nur ein Datenspeicher, ausser mir geht der interne Speicher aus, dann
lagere ich eventuell einige Binaries auf die Karte aus.
+/- schrieb:> Was sagt denn> eigentlich ein hdparm zu dem Teil, welche Infos gibt das Preis?
Das ist bei den beiden PCs etwas unterschiedlich, bei hdparam -i
bekomme ich bei beiden:
Mit hdparam -I bekomme ich beim einen PC das selbe wie oben, und mit
dem anderen dummy werte. Ich werde das nochmal versuchen, wenn das Handy
ankommt. Vermutlich liegt es nur am Card Reader oder am Treiber davon.
PS: Danke für die Links @+/- (Gast)
Was regst du dich überhaupt auf?
Als Datenspeicher ist das Filesystem wurscht.
Die Antwort von SanDisk hätte ich dir auch geben können.
Deine Bedenken wären nur relevant, wenn du sie als SSD mißbrauchen
wolltest.
> Warum nutze ich nicht den> Standart-Format des Endgerätes (wird wohl vFAT sein)?
Der entscheidende Punkt ist wohl die Rechteverwaltung und ein
vernuenftiger Umgang mit Gross/Kleinschreibung. Eventuell auch noch Soft
und Hardlinks.
Ich wuerde im uebrigen nicht auf das journal verzichten. Bei einer
Speicherkarte kann es ja mal vorkommen das man versehentlich die Karte
raus nimmt wenn sie nich gemountet ist. Dann laeuft die Ueberpruefung
danach deutlich schneller. Und bei einer als Datenkarte angedachten
Speicherkarte wuerde ich wenigstens -m0 als Parameter angeben. Sonst
werden ja defaultmaessig 5% des Speicherplatzes fuer root reserviert.
Olaf
michael_ schrieb:> Die Antwort von SanDisk hätte ich dir auch geben können.
Die Antwort hätte jeder geben können. Genau wie jede andere Antwort. Nur
dass deine Aussage wertlos ist. Im Gegensatz dazu, wenn die Aussage vom
Hersteller selber kommt.
Olaf schrieb:> Der entscheidende Punkt ist wohl die Rechteverwaltung und ein> vernuenftiger Umgang mit Gross/Kleinschreibung. Eventuell auch noch Soft> und Hardlinks.
Mmh, fuer 'embedded' Systeme wurde ich andere Kriterien zuerst
heranziehen also eher Geschwindigkeit und Wiederherstellbarkeit des
Dateisystems.
Die Wahrscheinlichkeit groesseren Datenverlusts scheint mit einem extFs
jedenfalls weitaus geringer. F2FS und NILFS2 sind halt noch recht neu
und BTRFS ist ein bisl 'fett'.
Hier gibt es noch einen interessanten Vortrag zum Thema,
[video/.webm 602M]
http://mirror.linux.org.au/pub/linux.conf.au/2015/Case_Room_2/Friday/SD_Cards_and_filesystems_for_Embedded_Systems.webm
Thread beobachten
Seitenaufteilung abschalten