Das Image ist nicht bootfähig, weil wohl am Ende eine Kleinigkeit fehlt
- der letzte 1M-Block lässt sich nicht schreiben.
Offenbar sind da ein paar Sektoren tot. Wann das Problem erstmals
aufgetreten ist, oder ob es womöglich schon von Anfang an bestand, weiß
ich leider nicht - die Karte habe ich noch keinen Monat. Laut Aufdruck
stammt sie von Samsung.
Nun aber zu meiner eigentlichen Frage:
Ich habe - wie üblich - dierekt nach dem Eintreffen alle Medien getestet
- diemal nicht mit dem C't-Test, sondern mit f3 unter Linux - der Test
lief fehlerfrei und tut es auch jetzt noch, wenn ich die Karte
formatiere.
Gibt es eine Möglichkeit, die Anzahl der vorhandenen Sektoren auf dem
Medium zu testen?
Uhu Uhuhu schrieb:> dd: error writing ‘/dev/sdb’: No space left on device
Steht doch schon da: No Spce left on device. Also kein Speicherplatz
mehr frei.
Wieso denkst du, das da die Karte ein fehler hat?
Und die Aufgedruckten 8 GB sind in Wahrheit nie 8 GB.
Hubert Mueller schrieb:> Steht doch schon da: No Spce left on device.
Hab ich was anderes behauptet? Offenbar hast du das Problem nicht
verstanden.
> Wieso denkst du, das da die Karte ein fehler hat?
Na was macht wohl der Kartencontroller, wenn er einen defekten Block
findet? Richtig, er hängt einen Reserveblockt ein, wenn welche dafür
vorgesehen sind; wenn nicht, dann hat die Karte eben einen Block
weniger.
Wenn ich eine 8GB-Karte kaufe, dann kann ich erwarten, dass da auch noch
8 GB verfügbar sind - nur merkt der f3-Test nicht, wenn es weniger sind.
Es wird also ein Test benötigt, um solche faulen Eier zu finden
damit man das Teil als defekt zurückgeben kann.
Danach habe ich gefragt.
> Und die Aufgedruckten 8 GB sind in Wahrheit nie 8 GB.
Wenn das wahr wäre, wäre das Verteilen von Kartenimages sinnlos.
Der o.g. Fehler kommt nur, wenn das Block device zu klein ist.
Mach also mal
1
sudo /sbin/blockdev --getsize64 /dev/sdb
und vergleiche das mit der Größe der Imagedatei. Ich vermute stark, dass
die Karte einfach ein paar 512 Byte Blöcke kleiner ist. Und ja, die
genaue Größe einer 8GB Karte ist nicht im Standard festgelegt.
Jim Meba schrieb:> sudo /sbin/blockdev --getsize64 /dev/sdb
Das funktioniert - danke für den Tipp.
Für die Karte wird 7861174272 = 7497 MB angezeigt
Eine andere, die bis jetzt keine Probleme gemacht hat, hat
7969177600 = 7600 MB
Ein 8GB USB-Stick hat nur 7636 MB
Ein 64GB USB-Stick (Billigheimer) hat nur 60500 MB
> Und ja, die genaue Größe einer 8GB Karte ist nicht im Standard festgelegt.
Wo ist das festgelegt?
Die bad blocks von SD-Karten und USB-Sticks werden wie bei Festplatten
auch beim low-level-Formatieren blockiert. Die guten werden unter
Markennamen teuer verkauft, bei den billigen no-name muß man Glück haben
mit der Kapazität.
Helge A. schrieb:> Die bad blocks von SD-Karten und USB-Sticks werden wie bei Festplatten> auch beim low-level-Formatieren blockiert.
Bei den Flash-Devices ist das noch neutlich komplizierter. Die
Speicherzellen haben keine sonderlich große Lebensdauer und damit nicht
nach 100000 Änderungen in einem Verzeichnis das ganze Medium reif für
die Tonne ist, wechselt der Controller die Zuordnung zwischen
Blockadresse und physikalischem Block bei jedem Schreibvorgang. Bei der
Gelegenheit werden "weiche" Blocks ausgesondert und gegen einen
Reserveblock ausgetauscht.
Kritisch wirds, wenn es keine Reserve mehr gibt.
Es gibt doch vom Heise eine Test-SW für USB Sticks, SD-Karten etc. Hab
ich selber mal gut brauchen können als eine 16 oder 32 G Sandisk Karte
nur eine 4G war.
Da hat der Ersteller des Images einfach die Größe seiner SD-Karte als
Wahrheit genommen und nicht weiter drüber nachgedacht. Kann man unter
"Anfängerfehler" verbuchen.
Die einfachste Lösung: Schreib das Image auf eine 16-GB-Karte.
Das Umarbeiten eines bootfähiges Images für eine kleinere Karte kann
richtig in Arbeit ausarten.
Konrad S. schrieb:> Die einfachste Lösung: Schreib das Image auf eine 16-GB-Karte.> Das Umarbeiten eines bootfähiges Images für eine kleinere Karte kann> richtig in Arbeit ausarten.
oder:
kopier von
Uhu Uhuhu schrieb:> Eine andere, die bis jetzt keine Probleme gemacht hat, hat> 7969177600 = 7600 MB
auf
Uhu Uhuhu schrieb:> Für die Karte wird 7861174272 = 7497 MB angezeigt
und benutze erstere für das image
Konrad S. schrieb:> Die einfachste Lösung: Schreib das Image auf eine 16-GB-Karte.> Das Umarbeiten eines bootfähiges Images für eine kleinere Karte kann> richtig in Arbeit ausarten.
Ich habs versucht und bin damit auf die Schnauze gefallen: gparted
startet vor dem Resize fsck und das beschwert sich dann, das Medium, in
dem Fall also das Loop-Device, über das das Image gemountet ist, müsste
entweder beschreibbar sein, oder die ganze Chose muss mit root-Rechten
gemacht werden.
Die Image-Datei ist beschreibbar und das Ganze lief unter root. Warum
dieses verfluchte fsck für ext3 auch von der Kommandozeile aus direkt
aufgerufen nicht will, weiß der Teufel.
Jim Meba schrieb:> cat /proc/mounts
Und was ist der Unterschied zum klassischen mount ohne Parameter?
> Dann muss natürlich vorher umount ran.
Das hat auch nichts geholfen. Weiß der Henker warum.
Ein 8GB Flash-Speichermedium hat grundsätzlich auch 8GB an
Flash-Speicher verbaut.
Ein Teil des Speichers wird jedoch für die Firmware bzw. die
Verwaltungsdaten der Karte gebraucht (allerdings nur ein paar KB), der
grösste Teil ist die sogenannte User-Area (den Teil auf den der Host
Zugriff hat, wo man Daten speichern kann).
Daneben wird noch ein Teil für die Reserveblöcke verwendet (Spare
Blocks). Geht ein Flash Block "kaputt" (Bad Block), tauscht ihn die
Karte intern (der User merkt davon nichts)mit einem Spare Block dem
Reservebereich aus.
Der User-Bereich bleibt also immer gleich gross! Hier unterscheiden sich
Flash-Speicherprodukte von traditionellen HDDs.
Allerdings ist dieser Bereich nicht bei allen Herstellern gleich gross,
da sich die Anzahl an Spare-Blöcken und somit die Grösse des
"Reservebereichs" je nach Hersteller unterscheiden kann. Wie viel Spare
gebraucht wird um eine möglichst lange Lebenszeit des Produktes zu
erreichen hängt von den eingesetzten Speichertypen ab. Somit haben
unterschiedliche Modell auch unterschiedlich viel "Speicherplatz". Zwei
Modelle der gleichen Serie sollten sich jedoch nicht Unterscheiden.
Swissbit schrieb:> Somit haben> unterschiedliche Modell auch unterschiedlich viel "Speicherplatz". Zwei> Modelle der gleichen Serie sollten sich jedoch nicht Unterscheiden.
Nach meinen bisherigen Tests liegt verfügbare Speicherplatz zwischen 5
und 10% unter der angegebenenen Größe.
