(Fortsetzung der Diskussion vom Thread Beitrag "Re: Wer von euch nutz Linux und warum") Ich habe versuchsweise einen 8GB Stick abwechselnd mit Win7 und Linux (Debian 8.3) FAT32 formatiert und dann mit dem Diskeditor untersucht. Es gibt in der Tat ein paar Unterschiede. Im MBR weicht die Zahl der Köpfe ab (Offset 01C2h: Linux 0Bh Win 0Ch) Im Bootsektor (siehe Bild1) unterscheiden sich die Syteme u.a. darin: - Offset 018h (Sektoren pro Spur) Linux 3Eh Windows 3Fh - Offset 01Ah (Anzahl Köpfe) Linux 7Ch Windows FFh - Offset 024h (Sektoren pro FAT) Linux D9h Windows D8h Weitere Differenzen findet man beim Volumenamen (obwohl beide die Datenträgerbezeichnung "TRANSCEND" haben und im Explorer/Dateimanager auch so erscheinen) und im ausführbaren Code ab Offset 05Ah. Unter Linux formatiert hat der Stick geringfügig mehr Kapazität (siehe Bild2). Struktur FAT32 http://www.easeus.com/resource/fat32-disk-structure.htm
Angehängte Dateien:
-
fat32-bootsect.png
97 KB -
Kapazitaet.jpg
61 KB
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.
Angehängte Dateien:
-
mbr-Win-HP.png
110 KB
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.
Icke ®. schrieb: > Ich habe versuchsweise einen 8GB Stick abwechselnd mit Win7 und Linux > (Debian 8.3) FAT32 formatiert Mich wuerde interessieren mit welchen Tools (unter Linux) du die Formatierung gemacht hast? GParted? fdisk & mkfs? Andere Tools?
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.)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Normalerweise hat ein guter Halbleiterspeicher mehr Zellen als wir sehen (um die Ausbeute zu verbessern hat man mir erklärt). Die fehlerhaften wurden dann rechtzeitig weggeschaltet. A. H. schrieb: > das Layout des Speichers Eigentlich sind ja 2 Baustellen: 1. Linux formatiert anders als MS die FAT (siehe icke-Bild). Frage ist dann ob hinterher jedes andere System es richtig erkennt. 2. Ob Du beim Formatieren jede Speicherzelle NEBEN der anderen ODER wie vom Hersteller gewollt irgendwo beschreibst, könnte z.B. unterschiedliche Wärmebelastung des Chips zur Folge haben. Evtl. werden dabei schon fehlerhafte Stellen ausgelagert?
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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!
oszi40 schrieb: > 1. Linux formatiert anders als MS die FAT (siehe icke-Bild). Frage ist > dann ob hinterher jedes andere System es richtig erkennt. Für mich interessant wären noch wie es aussieht, wenn man z.b. eine SD-Karte in einer Kamera formatiert. Es gebe da 3 Möglichkeiten: a) gleiches Ergebnis wie unter Windows b) gleiches Ergebnis wie unter Linux c) ganz anderes Ergebnis Ich halte b) oder c) für wahrscheinlich. Dan Könnte man nochmal ein Vergleich zwischen Windows 98 und Windows 7/8 machen. Ggf. hat sich da mal was geändert, wurde aber in Linux nicht übernommen.
Icke ®. schrieb: > Die Lage der Partition wird aber beim Formatieren nicht verändert, Die Lage der FAT und des Datenbereichs ist aber auch relevant und einstellbar, und das kann beim normalen Formatieren ohne schlaue Tools schief gehen. Btw: Von der SD Group gibt es genau aus den genannten Gründen für SD Karten ein Formatierungstool, das alle diese Feinheiten beachtet.Für SD Karten ist das Layout von Partition und Dateisystem aber auch genau spezifiziert.
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.
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.