Daten auf USB Stick schreiben - Debian Unstable (Kanotix-HD-Install)

Thu Oct 13 16:10:09 CEST 2005

Jörg Grafe wrote:
> Am Donnerstag, 13. Oktober 2005 02:19 schrieb Jan 'RedBully' Seiffert:
> 
> 
>>Jedoch sollte man fuer Flash-Speicher (ob USB-Stick oder CF) *nicht*
>>sync benutzen. Flash-Speicher haben meistens ein FAT-Dateisystem (wenn
>>man das nicht aendert und naja, das als Austauschmedium Kompatibel
>>halten will), so das die sync-option dazu fuehrt, das nach jedem Block
>>(512 byte) einer Datei die File Allocation Table vorne im immmer
>>gleichen Block des Flash neu geschrieben wird (Da ja nun ein weiterer
>>Block belegt ist). Der hat dann Ruckzuck seine 1000 Schreibzyklen rum,
>>und der Speicher ist "kaputt". 
> 
Ok, war spaet gestern...
Erstmal eine kleine Korrektur: die FAT wird natuerlich nicht nach jedem
Block neu geschrieben (512 Byte), sondern nach jedem logischen FS-Block
(wenn sync gesetzt ist und der je nach dem wann der Kernel (je nach
Version) sich dazu berufen fuehlt, das wegzuschreiben). Deren groesse
haengt bei FAT von der gesammtgroesse des FS ab (zumindest wenn org.
MS-Utils das formatieren, unter Linux kann man die groesse natuerlich,
in gewissem Rahmen, bei mkfs einstellen). Typische groessen sind 2 bis 16k.

> 
> da ich Daten meist sowieso nur unter linux austausche werde ich die Sticks mit 
> ext3 formatieren um diesen Effekt zu vermeiden oder welches Dateisystem soll 
> ich nehmen ?
So, gaaaanz langsam.
Bei ext3 (und anderen FS) ist das Journal nicht gut fuer den Flash, das
hatte Jan-Benedict ja schon erwaehnt (es sei denn, man benutzt eine
externe Journaldatei auf z.b. der Festplatte, aber wie sinnvoll das ist...).

Ich wollte dich eigentlich *nicht* dazu verleiten, ein anderes FS zu
benutzen. Es ist wohl der falsche Eindruck entstanden, dass das ein
Problem von FAT alleine ist. Grundsaetzlich hat fast jedes FS dieses
Problem. FS-Metainformationen liegen in den immer gleichen Bloecken und
werden durch "arbeiten" (rw) mit dem Medium regelmaessig beschrieben.
Bei ext sind das z.B. die Bitmaps fuer freie Blocke und die
Inode-Tabellen, die "bewegen" sich auch nicht ueber das Medium. Der
Vorteil bei ext ist nur, das schon mehr informationen (Dateinamen,
Blockzuordungen ueber IMHO ~8 Bloecke) ueber das Medium verstreut liegen.
FAT ist da einfach nur empfindlicher, es liegen einfach *alle* infos in
der _F_ile_Allocation_T_able die ein paar Blocke am Anfang des Mediums
einnimmt (plus die kopie am ende?).
Wenn natuerlich der Superblock fuer ext auch alle paar Sekunden
geschrieben wird, wie das Florian erwaehnte, dann kann man das auch
vergessen, da ist dann ext empfindlich, der liegt naehmlich auch im
immer gleichen Block (muss er ja auch, damit in das OS findet, is ja das
erste was gelesen wird). Ob da konkret "noatime" und "nodiratime"
abhilfe schaffen, weiss ich nicht (aber sie sind auf jeden Fall fuer ein
ext auf Flash sinnvoll, oder gleich ro mounten).

FAT hat aber auch Vorteile:
sein Platzeigenbedarf ist geringer, man bekommt also mehr aufs Medium.
(nagut, 32 MB Sticks sind mittlerweile veraltet, aber die ganzen
CFs/Smartmedias/etc. fuer Kamaras...)
Es ist einfacher, so das man jedem µ-Controller FAT-Lesen (und
schreiben) beibringen kann. Auch wenn du jetzt sagst, du benutzt
hauptsaechlich Linux, deine Ext-Sticks werden wohl nicht an den Radios
mit USB-Anschluss, auf der Party von nem Freund mit Windows (gut wenn
man ein paar MP3s seiner Lieblingsmusik immer dabei hat ;) oder am
Digitalphoto-Bestell-Terminal funktionieren. (Sidenote: einfacher ist
relativ, fuer ext kann man sich die Specs einfach runter laden und
danach Programmieren, mal abgesehen vom M$-FAT-Patent gehampel...)

Abhelfen koennen hier nur intelligente FlashController (die halt das
interface bilden zwischen Flashchip und "Stecker"), die z.B. bei jedem
Schreibzugriff immer erstmal einen "neuen Leerblock" nehmen (was
natuerlich schwierig wird wenn der Stick voller wird), oder andere
Rotationsprinzipien. Auch das automatische (fruehzeitige) Erkennen von
Blockversagen und die Benutzung von Reservebloecken ist eine
Moeglichkeit. Interne Zaehler wie haeufig ein Block schon geschrieben
wurde und ausweichen auf einen mit niedrigerem Zaehler koennte auch
helfen. Ganz grosse Eisenbahn ist das transparente cachen von
Schreibanforderungen im Flashcontroller, so das er writes in den immer
gleichen Block erstmal zusammen fasst, das ist nur schwierig, da im
falle eines Stromausfalls (einfach abziehen...) mit "Restenergie" die
Daten sicher permanent weggeschrieben werden muessen (wenn ein
Herrsteller sowas macht, dann macht er es erstmal wieder sicher fuer FAT
optimiert, er cached nur die ersten Bloecke so das er den Cache klein
halten und ihn laenger puffern kann, naja, plus dass das unter Win nicht
so das Problem zu sein scheint, dort scheint es ja eine Zwischenstufe zu
geben zwischen "normal" und sync, solche Technik landet dann wohl in
extrateuren Industrie-CFs...).
Ob "dein" billiger Medion Stick irgendwas davon implementiert, siehst
du, wenn das Licht an^waus geht, es also zu spaet ist. Aber auch mit dem
Markenflash von z.B. Sandisk kann dir das passieren, weil du grad die
Consumerreihe erwischt hast (Modellbezeichnungen sind selten konsistent
und Techn. Indeep-Doku (was machen die denn da drin) rar).

Wo ich eher draufhinaus wollte ist, sync nicht zu benutzen. Fuer den
Heimgebrauch tut es eben auch der "dumme" Flash, da sind 1k-10k
Schreibzyklen viel. Sync treibt das nur schneller ans Limit, im
unguenstigtens Fall zu schnell. Ohne sync muss man dann zwar dran
denken, den Stick auszuhaengen (und gegebenenfals am tragbaren Geraet
_vorher_ mal schauen, ob der Akku noch haelt), aber schon alleine der
Performancegewinn ist es bei grossen Datenmengen wert ("mal /grad/ das
ISO kopieren..."), Kopierbefehl absetzen, es tut sich ertmal nichts
(alles im VFS cache), ein sync in die console absetzen und es wird,
recht fix (was das Medium hergibt), alles ausgeschrieben.
Wenn ein Automounter nauerlich automatisch sync setzt, ist das etwas
schwieriger, aber die richtige Loesung ist und bleibt sync nicht zu
benutzen,  wenn man es nicht braucht. Sync ist in diesem Fall der
killer, da es die Menge der Schreibzugriffe drastisch erhoeht, mit
Caches und der moeglichkeit Schreibzugriffe zu optimieren (eben auch auf
die FAT) sinkt derer Zahl auf normal/kein Problem/nicht erwaehnenswert.

> Grüsse und vielen Dank
> 
> Jörg
Gruss
	Jan

-- 
In Daenemark sagt man, dass das papierlose Buero spaetestens
auf der Toilette ein gar boeses Ende findet.