FAT32 Format Unterschiede Linux - Windows

Sieht eigentlich alles nicht weltbewegend aus.  Die blöden Anzahlen
von Sektoren und Zylindern sind sowieso eins der grundlegenden
Fehldesigns (logische Blocknummern wären besser gewesen), und da
heutige Datenträger in diesem alten INT13-Schema sowieso nicht mehr
darstellbar sind, rechnet da jeder einfach nur irgendwas aus.

Interessant ist, dass Windows an der Stelle des klassischen volume
names nur „NO NAME“ einträgt, dann offensichtlich den Namen woanders
hinterlegt …

Beim Acronis-Problem aus dem anderen Thread ist mir noch gar nicht
klar, ob das eher eins mit dem MBR ist und gar nicht mit dem FAT oder
NTFS selbst.

Jörg W. schrieb:
> Beim Acronis-Problem aus dem anderen Thread ist mir noch gar nicht
> klar, ob das eher eins mit dem MBR ist

Wahrscheinlich schon. Das HP USB Format Tool..

http://www.chip.de/downloads/HP-USB-Disk-Storage-Format-Tool_23418669.html

...mit dem Sticks bootfähig gemacht werden können, setzt bspw. die 
Partition inaktiv und schreibt anderen Bootcode rein (siehe Bild). 
Acronis müßte eigentlich auch ähnliches tun.

jetzt habe ich Leute dazu bewogen Arbeit zu machen ;)

beim rechten Bild war ich unlängst auch schon,
das linke sagt mir als Nichtprogrammierer nur soviel, dass die 
Unterschiebe bereits beim 4. Byte anfangen und es sonst auch deutliche 
Unterschiede gibt.

nur dass Sticks dann so selektiv (durch einzelne Programme)
nicht erkannt werden ist schon echt schräg.

Linux bringt also mehr Speicherkapazität hervor.
liegts daran dass einige Cluster/Zellen mehr frei sind?

und:
Unterschiede bei richtigen Festplatten wären auch noch interessant.

Kaj schrieb:
> Andere Tools?

Mit dem Gnome Dateimanager. Keine Ahnung, was der im Hintergrund dafür 
nutzt.

Das sollte keine rolle spielen, weil fdisk keine Partitionen Formatieren 
kann und gparted und co. auch nur mkfs aufrufen. Ausserdem steht mkfs im 
1ten Screenshot 4tes Zeichen.

▶ J-A von der H. schrieb:
> das linke sagt mir als Nichtprogrammierer nur soviel, dass die
> Unterschiebe bereits beim 4. Byte anfangen und es sonst auch deutliche
> Unterschiede gibt.

Das ist genau das, was ich meinte, als ich schrieb, dass es da keine
einfache Antwort auf deine Frage gibt, was denn da nun anders wäre.

Daniel A. schrieb:
> Das sollte keine rolle spielen, weil fdisk keine Partitionen Formatieren
> kann und gparted und co. auch nur mkfs aufrufen.

Das denke ich auch. Und gemäß Manpage von mkfs.vfat:
http://linux.die.net/man/8/mkfs.vfat

gibt es diverse Optionen, welche bei verschiedenen Einstellungen die von 
Icke gefundenen Unterschiede hervorrufen könnten.

Also erst einmal ist es in der Regel keine gute Idee, ein Flash-Device 
neu zu formatieren, es sei denn, man weiß genau was man tut oder nimmt 
in Kauf, es gegebenenfalls zu ruinieren. Eine Erklärung dazu findet sich 
hier:

http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

Das könnte auch erklären, warum unterschiedlich Betriebssysteme 
unterschiedliche Layouts bevorzugen, je nach dem, wie stark solche 
Aspekte standardmäßig berücksichtigt werden.

Zum Problem der Volume Labels gibt es eine Erklärung hier:

https://bugzilla.novell.com/show_bug.cgi?id=657011#c4

Man sollte unter Linux wenigstens die Version 3.0.16 der dostools 
benutzen, um Probleme zu vermeiden. (Sollte unter Debian 8.3 aber wohl 
kein Thema sein.)

So viel zu „Standard“. ;-)

A. H. schrieb:
> Also erst einmal ist es in der Regel keine gute Idee, ein Flash-Device
> neu zu formatieren, es sei denn, man weiß genau was man tut oder nimmt
> in Kauf, es gegebenenfalls zu ruinieren.

Eine vollständige Formatierung macht natürlich keinen Sinn, das ist 
richtig. Quickformat, wie ich ich es praktiziert habe, richtet aber 
keinen Schaden an, denn da wird außer FAT, Directory, MBR und Bootsektor 
nichts beschrieben.

Hallo Icke.

Icke ®. schrieb:
> A. H. schrieb:
>> Also erst einmal ist es in der Regel keine gute Idee, ein Flash-Device
>> neu zu formatieren, es sei denn, man weiß genau was man tut oder nimmt
>> in Kauf, es gegebenenfalls zu ruinieren.

> Eine vollständige Formatierung macht natürlich keinen Sinn, das ist
> richtig. Quickformat, wie ich ich es praktiziert habe, richtet aber
> keinen Schaden an, denn da wird außer FAT, Directory, MBR und Bootsektor
> nichts beschrieben.

Die meisten USB Sticks werden so extrem schnell "formatiert", dass ich 
vermute, dass "formatieren" dort bedeutet, der Stick Verwaltung 
mitzuteilen, wie sie sich nach aussen darstellen soll.
Wie die die Daten intern handhabt, ist wohl eine andere Sache.

Persönlich habe ich gute Erfahrung dami gemacht, die Sticks auf FAT32 
umzuformatieren, weil ich immer noch auf überraschend viele W95 Rechner 
stosse, die NTFS nicht kennen.
Abgesehen davon macht FAT32 kein Journalling, was bedeutet, das weniger 
oft schreibend darauf zugegriffen wird, was die Speichermedien auch 
schont.
Vermutlich ist das bei neueren Sticks auch weniger ein Problem. Für 
Journalling könnte z.b. ein besonders robuster Speicherbereich 
(Ferroelektrika?) verwendet werden.

Was weiter schonend wirkt, ist die Verwendung von rsync oder 
vergleichbarem um meine Ordner zu synchronisieren. Das ist wesentlich 
effizienter, als den Ordner zu löschen und neu zu schreiben. 
"Fragmentierung" kann ich dabei auch kaum beobachten....siehe oben meine 
Vermutung, dass der Stick das intern auf seine eigene Tour handhabt.

Zur 2GB Grenze von FAT32: Ich bin noch nie dagegen gestossen. Da ich 
kein Video-Gucker bin, ist das eher leicht. Mein E-Mail Archiv könnte 
irgendwann mal dort anstossen. Aber das dauert noch.....

Seit 2011/2012 sind mir bisher nur Sticks kaputtgegangen, weil sie mir 
mechanisch zerbrochen sind. Obwohl die auch robuster geworden sind. Ich 
habe eine selbstgenähte Geldbörse aus LKW Plane mit zwei USB Stick 
Fächern.
Die habe ich letztens auch noch mit zwei Sticks (32GB und 64GB) durch 
die 40 Grad Wäche gejubelt, und dann noch mit 1400 Umin geschleudert. 
Beide haben überlebt. Ich habe sie aber vorsichtshalber vor 
Wiederinbetriebnahme
auch eine Woche getrocknet.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

Icke ®. schrieb:
> Eine vollständige Formatierung macht natürlich keinen Sinn, das ist
> richtig. Quickformat, wie ich ich es praktiziert habe, richtet aber
> keinen Schaden an, denn da wird außer FAT, Directory, MBR und Bootsektor
> nichts beschrieben.

Aber leider mit für die Lebensdauer und Performance des Flash Speichers 
ungünstigen Werten.

Icke ®. schrieb:
> Eine vollständige Formatierung macht natürlich keinen Sinn, das ist
> richtig. Quickformat, wie ich ich es praktiziert habe, richtet aber
> keinen Schaden an, denn da wird außer FAT, Directory, MBR und Bootsektor
> nichts beschrieben.

Das Problem hier ist nicht die Last, die das Formatieren selbst erzeugt, 
sonder ein Phänomen, das sich Write Amplification nennt. Es beschreibt 
den Effekt, dass die physisch auf dem Device zu schreibende Datenmenge 
um ein Vielfaches größer sein kann als das, was vom Host an das Gerät 
gesendet wurde. Dieser Effekt kann Lebensdauer und Performance des 
Gerätes massiv beeinträchtigen. Er tritt besonders dann auf, wenn das 
Layout des Dateisystems nicht an das Layout des darunter liegenden 
physischen Speichers angepasst ist. Dazu muss man das Layout des 
Speichers natürlich erst einmal kennen. Allerdings macht man nichts 
falsch, wenn man die Parameter des herstellerseitig aufgebrachten 
Dateisystems übernimmt. Ob Quickformat das tut, da hätte ich allerdings 
meine Zweifel.

A. H. schrieb:
> Das Problem hier ist nicht die Last, die das Formatieren selbst erzeugt,
> sonder ein Phänomen, das sich Write Amplification nennt.
...
> Ob Quickformat das tut, da hätte ich allerdings
> meine Zweifel.

Bei Quickformat entsteht überhaupt keine nennenswerte Schreiblast. Denn 
da werden nur die FATs, das Inhaltsverzeichnis, der Bootsektor und evtl. 
der MBR neu beschrieben. Alles in allem höchstens ein paar Kilobyte. Die 
Methode ist für den Stick sogar schonender als eine nennenswerte Anzahl 
von darauf befindlichen Dateien zu löschen, weil nämlich beim Löschen 
einer jeden Datei FATs und Directory aktualisiert werden müssen, anstatt 
nur einmalig beim Quickformat.
Davon abgesehen weiß ein schnöder USB-Stick rein gar nichts vom 
Dateisystem. Das Wearleveling arbeitet auf Blockebene und ihm ist es 
völlig wurst, ob FAT, NTFS, EXT oder RAW auf ihm rumrödeln. Funktionen, 
die das Dateisystem berücksichtigen (TRIM) oder analysieren, gibt es 
(derzeit) nur bei SSD-Festplatten.

Icke ®. schrieb:
> Das Wearleveling arbeitet auf Blockebene und

Ich würde lieber von Page-Ebene sprechen um unmissverständlich klar zu 
machen, dass es sich hier um die Pages des Flash-Speichers handelt und 
nicht etwa die Blöcke des Dateisystems.

> ihm ist es völlig wurst, ob FAT, NTFS, EXT oder RAW auf ihm rumrödeln.

Das ist erst einmal richtig. Weniger egal ist dem Speicher allerdings 
das Zugriffsmuster, dass ein Dateisystem erzeugt. Das in-place Update 
eines einzelnen 512 Byte Blockes etwa (oder um im Windows-Jargon zu 
bleiben: eines 512 Byte Sektors) erfordert immer das Schreiben einer 
ganzen Page und Pages haben heute Größen von oder jenseits der 16 kB. 
Wenn eine logisch zusammenhängende Dateneinheit, wie zum Beispiel ein 
Cluster, die Grenzen einer Erase Region überschreitet kann dies eine 
Garbage Collection auslösen und zur Folge haben, dass der noch gültige 
Inhalte einer ganzen Erase Region neu geschrieben werden muss. Erase 
Regions haben heute Größen in der Größenordnung von 4 MB. Im Interesse 
von Performance und Langlebigkeit haben Clusters daher idealerweise die 
Größe einer Page (oder einer Zweipotenz davon) und sind an den Grenzen 
der Erase Regions ausgerichtet. Auch der FAT sollte keine Grenze 
zwischen Erase Regions überschreiten und darüber hinaus keine Region mit 
Cluster-Daten teilen. Ich halte es nach wie vor für ziemlich 
optimistisch zu erwarten, dass ein einfaches Quickformat all diese 
Randbedingungen einhalten kann.

PS: Bei anderen Dateisystemen ist eine solche Optimierung noch 
schwieriger.

Icke ®. schrieb:
> Bei Quickformat entsteht überhaupt keine nennenswerte Schreiblast. Denn
> da werden nur die FATs, das Inhaltsverzeichnis, der Bootsektor und evtl.
> der MBR neu beschrieben. Alles in allem höchstens ein paar Kilobyte.

Es geht nicht um die Last beim Formatieren sondern danach bei der 
Benutzung mit dem neuen Offset und den neuen Blockgrößen.

Btw: Ich hab grad mal in gparted nachgeschaut, dort kann man auswählen 
ob man  am Zylinder, an 1 MiB oder gar nicht ausrichten will, Default 
ist Ausrichtung an 1 MiB und wenn ich auf einem Stick eine neue 
Partition erzeuge mit Default-Einstellungen dann ist der kleinstmögliche 
Anfang den ich wählen kann 2 MiB (4096 Sektoren).

Nur wenn ich "Zylinder" einstelle (und das muss man wirklich vorsätzlich 
machen weil es jedesmal wieder auf 1MiB zurückspringt wenn man das 
Fenster schließt) schaffe ich einen krummen Anfang bei Sektor 63 
einzustellen. Also mit einem Partitionsbeginn bei 2MiB (also den 
Defaulteinstellungen von gparted) müsste ich doch was das Alignment 
angeht auf der sicheren Seite sein und den in dem oben verlinkten "How 
to damage.." beschriebenen Problemen komplett aus dem Weg gehen, oder?

Bernd K. schrieb:
> wenn ich auf einem Stick eine neue
> Partition erzeuge mit Default-Einstellungen dann ist der kleinstmögliche
> Anfang den ich wählen kann 2 MiB (4096 Sektoren).

> Also mit einem Partitionsbeginn bei 2MiB (also den
> Defaulteinstellungen von gparted) müsste ich doch was das Alignment
> angeht auf der sicheren Seite sein und den in dem oben verlinkten "How
> to damage.." beschriebenen Problemen komplett aus dem Weg gehen, oder?

Laut Link ist das so pauschal nicht gegeben, sondern hängt von der 
tatsächlichen Pagesize des verwendeten Flashs ab. Es ist ja auch als 
Beispiel eine Speicherkarte genannt, bei der die erste Partition ab 
Sektor 8192 beginnt.

Ausserdem ist die Ausrichtung der Partitionsgrenzen nur eine notwendige, 
aber keine hinreichende Voraussetzung für optimalen Betrieb des 
Flashspeichers. Obendrauf kommt dann ja noch das Dateisystem, dessen 
logische Einheiten passend gewählt werden müssen.

J.-u. G. schrieb:
> Laut Link ist das so pauschal nicht gegeben, sondern hängt von der
> tatsächlichen Pagesize des verwendeten Flashs ab. Es ist ja auch als
> Beispiel eine Speicherkarte genannt, bei der die erste Partition ab
> Sektor 8192 beginnt.
>
> Ausserdem ist die Ausrichtung der Partitionsgrenzen nur eine notwendige,
> aber keine hinreichende Voraussetzung für optimalen Betrieb des
> Flashspeichers. Obendrauf kommt dann ja noch das Dateisystem, dessen
> logische Einheiten passend gewählt werden müssen.

Das leuchtet mir ehrlich gesagt nicht ein:

8192 Sektoren wären dann in dem obigen Fall 4MiB, also kann das Flash 
nur in 4MiB-Blöcken löschen (bisschen viel auf einmal, oder), welche 
logische Sektorgröße wäre denn überhaupt noch sinnvoll? Ich hab noch nie 
was von nem Dateisystem gehört das 4MB-Sektoren verwendet. Sind die 
Sektoren zu klein muss er 99% unnötig löschen oder umkopieren, jedoch 
ist die Chance sehr gering (null?) daß ein Sektor die Grenze überlappt, 
wie soll das überhaupt gehen, alle Größen von Sektoren sind 2^n und der 
Offset fällt glatt auf ein 2^m-faches der Sektorgröße und die 
Page-Grenze ist wiederun ein 2^l faches des Offsets. Auf den ersten 
Blick erscheint es mir unmöglich hier einen Sektor über eine Page-Grenze 
zu überlappen. Auf den zweiten Blick auch.

Wenn die Pagegröße wirklich so enorm ist dann ist es also doch völlig 
Banane wie groß die Sektoren sind, Hauptsache die Page-Größe ist ein 
Vielfaches davon und der Offset ist eine 2er-Potenz und größer oder 
gleich ein FS-Sektor.

> 8192 Sektoren wären dann in dem obigen Fall 4MiB, also kann das Flash
> nur in 4MiB-Blöcken löschen (bisschen viel auf einmal, oder), welche
> logische Sektorgröße wäre denn überhaupt noch sinnvoll?

Ein Flash-Speicher kann in der Tat nur ganze Regions löschen und die 
liegen in der Tat in der Größenordnung von 4 MiB. Eine einmal gelöschte 
Region kann dann aber Page-weise sequentiell beschrieben werden. Eine 
einmal geschrieben Page kann aber nicht wieder überschrieben werden. 
Statt dessen wird die alte Page als stale markiert und eine neue Kopie 
der Page angelegt. Wo das geschieht und wie viele Daten dabei noch zu 
kopieren sind hängt von der Intelligenz des Wear Levelling ab, 
spätestens jedoch, wenn als stale markierte Pages recycelt werden sollen 
(garbage collection) müssen alle non-stale Pages in eine neue Region 
umkopiert werden. Eine gute Beschreibung findet sich hier:

https://lwn.net/Articles/428584/

Die ideale Blockgröße für das Dateisystem wäre also eine Page. Da aber 
auch Pages schon bei >= 16 KiB liegen ist ein gutes Layout eigentlich 
nur mit Clustern zu erreichen.

Bernd K. schrieb:
> 8192 Sektoren wären dann in dem obigen Fall 4MiB, also kann das Flash
> nur in 4MiB-Blöcken löschen (bisschen viel auf einmal, oder),

Hier:
http://flashdba.com/2014/06/20/understanding-flash-blocks-pages-and-program-erases/
ist sogar von bis zu 8MB blocksize die Rede.

> Ich hab noch nie
> was von nem Dateisystem gehört das 4MB-Sektoren verwendet.
So wie ich das verstanden habe (ich behaupte keinesfalls, dass das 
richtig ist) ist "Sektor" eine Einheit des Laufwerks. Üblich sind hier 
Größen von 512 oder 4096 Bytes. Dateisysteme verwenden als kleinste 
adressierbare Einheiten das "Cluster", welche im Falle von FAT aus 1 bis 
128 Sektoren bestehen kann.

Neben den Nutzdaten enthält das Dateisystem noch diverse 
Verwaltungsinformationen. Üblicherweise befinden sich diese zu Beginn 
einer Partition vor den Nutzdaten. Sinnvoll ist es, die 
Verwaltungsinformationen von den Nutzdaten zu trennen. Deshalb sollte 
dafür Sorge getragen werden, dass zwischen Verwaltungs- und Nutzdaten 
eine Blockgrenze des Flashspeichers liegt. Die Hersteller von 
Speicherkarten fügen zu diesem Zweck eine geeignete Zahl "ungenutzter 
Sektoren" ein. Und um das richtig zu machen, benötigt man die Blockgröße 
des Flashspeichers.

J.-u. G. schrieb:
> Dateisysteme verwenden als kleinste adressierbare Einheiten das
> "Cluster"

"Cluster" ist eine FAT-Kategorie.  Das gibt's sonst nirgends.

Berkeley FFS bspw. benutzt Blöcke, die in 8 Fragmente geteilt werden
können (um effizient auch kleine Dateien verwalten zu können).  Früher
waren mal 4 KiB / 512 B üblich, heute eher 16 KiB / 2 KiB.  Durch die
Fragmente (die man nicht mit der Fragmentierung von FATFS verwechseln
darf!) kann man den „Verschnitt“ bei kleinen Dateien gering halten und
trotzdem größere Dateien ohne zu viel „Kleinstaaterei“ verwalten.

Weiß gar nicht, was ZFS da macht.  Aber das ist für einen USB-Stick
vielleicht auch etwas Overkill. ;)

A. H. schrieb:
> Ich halte es nach wie vor für ziemlich
> optimistisch zu erwarten, dass ein einfaches Quickformat all diese
> Randbedingungen einhalten kann.

Doch, gerade Quickformat. Worauf es in erster Linie ankommt, ist das 
Alignment. d.h. die Ausrichtung des Partitionsanfangs. Die Lage der 
Partition wird aber beim Formatieren nicht verändert, sondern nur beim 
Partitionieren. Solange der Stick also nicht neu partitioniert wird, 
ändert sich auch das werksseitig voreingestellte Alignment nicht. Beim 
Formatieren kann allenfalls die Clustergröße falsch gewählt werden. Um 
die optimal einzustellen, müßte man wissen, mit welchen Blockgrößen der 
Stick intern arbeitet. Verläßliche Angaben sind schwer zu finden, aber 
gängige Größen liegen wohl bei 4, 8 und 16K und so sollte auch die 
Clustergröße gewählt werden. Mit größeren Clustern ist man auf der 
sicheren Seite, verschenkt jedoch Platz bei vielen kleinen Dateien.

Das Alignment läßt sich mit ASSD-Bench prüfen.

http://www.heise.de/download/as-ssd-benchmark.html

Ist eigentlich für SSDs gedacht, funktioniert aber auch mit Sticks.

Bernd K. schrieb:
> Es geht nicht um die Last beim Formatieren sondern danach bei der
> Benutzung mit dem neuen Offset und den neuen Blockgrößen.

Nicht Partitionieren und Formatieren durcheinander bringen. Der Offset 
(Alignment) ändert sich nur beim Partitionieren.

Icke ®. schrieb:
> Das HP USB Format Tool..
>
> http://www.chip.de/downloads/HP-USB-Disk-Storage-Format-Tool_23418669.html
>
> ...mit dem Sticks bootfähig gemacht werden können, setzt bspw. die
> Partition inaktiv und schreibt anderen Bootcode rein (siehe Bild).

Ein Hinweis dazu. Mir ist beim Durchtesten meiner eigenen Sticks mitt 
ASSSD-Bench aufgefallen, daß bei zweien davon das Alignment nicht 
stimmte. Das waren genau die, welche ich mit dem HP Tool bootfähig 
gemacht hatte. Die Gegenprobe bestätigte es, das HP Tool partitioniert 
den Stick neu und setzt das Alignment auf ungünstige 31K. Es sollte also 
tunlichst nicht verwendet werden!

USB mass storage devices werden wie SCSI Platten über das "SCSI 
transparent command set" angesteuert. Da gibt es nur Blockgröße und 
Anzahl der Blöcke und keine Sektoren Köpfe oder ähnliches.

Bei einer FAT Formatierung muss halt irgend etwas in die entsprechenden 
Felder der PartitionEntry im MBR geschrieben werden aber das hat mit der 
physikalischen Formatierung nichts zu tun.