langlebige und schnelle USB Sticks (NAND SLC mit wear leveling)
Andreas Weber
Momentane Situation:
Eine MSSQL Datenbank l�uft auf einem USB-Stick (4polig, male).
In die Datenbank werden sek�ndlich etwa 120 Byte geschrieben,
Lesezugriffe eher selten und azyklisch. OS ist Windows XP embedded,
Dateisystem ist NTFS, "write cache" ist aktiviert �ber "Explorer,
Properties, Optimize for Performance" (siehe dazu unten auch den Link zu
Windows write cache und "Plazebo Einstellungen")
http://www.uwe-sieber.de/usbstick.html
Momentan verwendeter Stick ist
idVendor 0x058f Alcor Micro Corp.
idProduct 0x6387 Transcend JetFlash Flash Drive
bcdDevice 1.42
iManufacturer 1 JetFlash
iProduct 2 Mass Storage Device
iSerial 3 Y2TG7FHS
Datenblatt zu dem Stick:
http://www.transcendusa.com/Support/DLCenter/Datasheet/TS4GJFT3.pdf
Dort steht "Erase Cycles >10,000 times" was auf MLC NAND schlie�en
l�sst, �ber wear leveling o.�. schweigen sie sich aus.
Problem:
nach ca. 1 Woche Dauerbetrieb steigt der Speicher mit defekten Sektoren
aus. Wurde mittlerweile mit 3 Sticks getestet. Der Stick wird sehr warm
im Betrieb, es k�nnte durchaus auch ein Temperaturproblem sein, welches
den Stick so schnell altern l�sst. (Momentan meine Vermutung)
Nun bin ich auf der Suche nach schnellen, und f�r die obige Anwendung
lange Haltbarkeit geeignete USB Sticks mit ca. 4GB.
Da stellen sich dann folgende Fragen:
+ Kann man Windows XP embedded dazu bringen den write cache zu
vergr��ern, bzw. was sind sinnvolle Einstellungen? Laut Link oben reicht
es, NTFS zu verwenden.
+ Swap (Auslagerungsdatei oder wie es bei MS heisst) war urspr�nglich
auch auf dem Stick und wurde nun deaktiviert. Ich k�nnte mir vorstellen,
dass dadurch viele Schreibzugriffe entstanden sind.
+ Welches Dateisystem ist daf�r geeignet? Unter Linux gibt es ja z.B.
JFFS2, ich bin aber hier unter Windows XP embedded. Da stehen mir
NTFS,FAT und exFAT zur Verf�gung.
exFAT http://www.golem.de/0902/65137.html
Macht ein spezielles Dateisystem wie exFAT �berhaupt noch Sinn, wenn
wear leveling verwendet wird? Meiner Meinung nach nicht. Angaben ob
dynamisches oder statisches oder �berhaupt wear leveling verwendet wird
gibt es selten.
+ NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
Flash best�ckt, also er�brigt sich die Frage quasi.
+ SLC (single level cell) oder MLC (multi level cell)? Die Haltbarkeit
von MLC wird mit >10.000 cyclen angegeben, bei SLC >100.000, also
bevorzuge ich SLC auch wegen dem h�heren Datendurchsatz
(Auf http://www.pc-experience.de/wbb2/thr...threadid=27187 wurden einige
SLC und MLC Typen getestet.)
+ F�r den verwendeten Stick gibt es ein "online recovery tool":
http://www.transcend.de/Products/online_recovery_1.asp
Welches die Sticks wieder kurzzeitig "heilen" kann. Was mich schon sehr
wundert, denn entweder sind die Zellen kaputt oder nicht. Und warum
braucht das Programm eine Onlineverbindung zu einem Server? Also sehr
dubios und mir unklar, was dieses Tool macht.
(Eher auch unwichtig, da ich im Produktionsbetrieb sicher nicht das
RecoveryTool als "L�sung" ansehe)
Eine Thesis zu dem Thema und ein Tool um Speicher zu testen:
http://rtg.informatik.tu-chemnitz.de/forschung/flash/flanatoo.php
Einige Typen, die ich in Betracht ziehe:
http://www.stec-inc.com/products/usbflashdrive/
Built-in Wear Leveling
Endurance Guarantee of 2,000,000 Write/Erase Cycles
Built-in ECC Engine: 5-bytes detection, 4-bytes correction
H�rt sich alles sehr toll an, leider noch kein H�ndler gefunden
Reichelt: OCZUSBR2TDC-4GB (leider kein Datenblatt, auch nach R�ckfrage
per EMail) OCZ setzt wohl Samsung und Micron Speicher ein, je nachdem
was g�nstiger auf dem Markt ist.
http://www.micron.com/products/partdetail?part=MTFDCAE004SAF-1B1IT
Leider nur 10poliger USB Anschluss, ansonsten von den Daten sehr
interessant.
von Transcend gibt es auch Industrial Versionen mit ausf�hrlicherem
Datenblatt:
http://www.transcendusa.com/support/dlcenter/datasheet/TS512M~4GUFM-V_H0409.pdf
Sieht dort nach DualChannel SLC aus, leider auch 10poliger USB Stecker.
(gibts f�r die umgekehrte Richtung Adapter oder m�sste ich da selbst was
bauen? 10polig male auf 2x4polig female gibts ja �berall als Slotblende)
Interessante Links:
http://www.heise.de/ct/artikel/Erinnerungskarten-290738.html
http://www.heise.de/ct/artikel/ueberflieger-291740.html
Eine Festplatte scheidet wegen Ersch�tterungen aus, eine SSD mit SATA
oder IDE ist zu gro� und die Schnittstellen daf�r nicht vorhanden.
Einziger anderer Ausweg w�re NAS mit SSD und ans Ethernet h�ngen.
Kosteng�nstig soll das halt auch noch sein.
Also, liebe NG Gemeinde: Hat jemand einen Vorschlag?
Ich kann mir nicht erkl�ren dass der letzte Speicher so schnell den
Geist aufgegeben hat wenn heutzutage wear leveling schon Standard ist
und das Betriebssystem einen write cache hat. Gru� von Andy und TIA
Artur Kawa
> Hallo NG,
> Momentane Situation:
> Eine MSSQL Datenbank l�uft auf einem USB-Stick (4polig, male).
Ich finde es mutig.
> "write cache" ist aktiviert �ber "Explorer,
Das finde ich noch mutiger...
Warum nimmst Du nicht eine kleine SSD? Oder eine kleine Notebook-HD.
Beides ist doch eher f�r diesen Zweck gebaut worden als ein USB-Stick.
Gruss
Artur
Marcel Müller
Andreas Weber wrote:
> Nun bin ich auf der Suche nach schnellen, und f�r die obige Anwendung
> lange Haltbarkeit geeignete USB Sticks mit ca. 4GB.
[...]
> + Kann man Windows XP embedded dazu bringen den write cache zu
> vergr��ern, bzw. was sind sinnvolle Einstellungen? Laut Link oben reicht
> es, NTFS zu verwenden.
die Gr��e des Cache ist nicht das Problem. Die Frage ist, wie lange die
Inhalte darin verweilen, bis sie geschrieben werden. Wenn nichts los ist
schafft das Dateisystem die normalerweise schnellstm�glich weg.
Und 100-Byte Schreibzugriffe je Sekunde sind f�r Flash-RAMs nat�rlich
nicht so toll. Da werden immer 256kB oder so geschrieben. Das w�ren rund
150GB/Woche. Aber normalerweise sollte das Wear-Leveling das l�nger
abk�nnen. Aber wer wei�, wenn auch noch Index-Updates und
Transaktionslog-Eintr�ge dazukommen, sind es vielleicht ein paar mehr
Schreiboperationen pro Sekunde.
> + Swap (Auslagerungsdatei oder wie es bei MS heisst) war urspr�nglich
> auch auf dem Stick und wurde nun deaktiviert. Ich k�nnte mir vorstellen,
> dass dadurch viele Schreibzugriffe entstanden sind.
Einer pro Sekunde? Eher nicht.
> JFFS2, ich bin aber hier unter Windows XP embedded. Da stehen mir
> NTFS,FAT und exFAT zur Verf�gung.
> exFAT http://www.golem.de/0902/65137.html
> Macht ein spezielles Dateisystem wie exFAT �berhaupt noch Sinn, wenn
> wear leveling verwendet wird? Meiner Meinung nach nicht.
Eher deshalb nicht weil kein Dateisystem standardm��ig verhindern wird,
dass eine Datenbank in ihr DB-File schreibt. Die meisten Datenbanken
machen sowieso ihr eigenes Caching. Da sind selbst die
Cache-Einstellungen des Dateisystems Banane. => an den
Datenbankeinstellungen drehen.
> + NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
> Flash best�ckt, also er�brigt sich die Frage quasi.
Nein, die Frage er�brigt sich nicht. F�r den Einsatzzweck w�re NOR-Flash
genau das richtige. Und bei 4GB ginge der Preis auch noch. Als USB-Stick
d�rfte es aber schwer zu bekommen sein.
> + SLC (single level cell) oder MLC (multi level cell)? Die Haltbarkeit
> von MLC wird mit >10.000 cyclen angegeben, bei SLC >100.000, also
> bevorzuge ich SLC auch wegen dem h�heren Datendurchsatz
D�rfte �ber kurz oder lang ebenfalls schwer als USB-Teil zu bekommen sein.
Ich w�rde mich mal bei Flash-RAMs f�r Industrieanwendungen umsehen.
> Welches die Sticks wieder kurzzeitig "heilen" kann. Was mich schon sehr
> wundert, denn entweder sind die Zellen kaputt oder nicht.
Wieso? Es ist ein Block kaputt, nicht der Stick. Aufgrund des
Wear-Levelings haben die Dinger sowieso einige Reservebl�cke.
> Und warum
> braucht das Programm eine Onlineverbindung zu einem Server?
Hersteller Fragen.
> Reichelt: OCZUSBR2TDC-4GB (leider kein Datenblatt, auch nach R�ckfrage
> per EMail) OCZ setzt wohl Samsung und Micron Speicher ein, je nachdem
> was g�nstiger auf dem Markt ist.
Consumerware. Das hatten wir schon.
> von Transcend gibt es auch Industrial Versionen mit ausf�hrlicherem
> Datenblatt:
> http://www.transcendusa.com/support/dlcenter/datasheet/TS512M~4GUFM-V_H0409.pdf
Jetzt stimmt die Richtung.
> Sieht dort nach DualChannel SLC aus, leider auch 10poliger USB Stecker.
> (gibts f�r die umgekehrte Richtung Adapter oder m�sste ich da selbst was
> bauen? 10polig male auf 2x4polig female gibts ja �berall als Slotblende)
Das Problem sollte sich ja l�sen lassen.
> Ich kann mir nicht erkl�ren dass der letzte Speicher so schnell den
> Geist aufgegeben hat wenn heutzutage wear leveling schon Standard ist
> und das Betriebssystem einen write cache hat.
Wie gesagt, Write-Cache vom OS bringt bei der DB nichts.
Marcel
Otto Sykora
>
>Datenblatt zu dem Stick:
>http://www.transcendusa.com/Support/DLCenter/Datasheet/TS4GJFT3.pdf
>Dort steht "Erase Cycles >10,000 times" was auf MLC NAND schlie�en
>l�sst, �ber wear leveling o.�. schweigen sie sich aus.
ja MLC
>
>Problem:
>nach ca. 1 Woche Dauerbetrieb steigt der Speicher mit defekten Sektoren
>aus. Wurde mittlerweile mit 3 Sticks getestet. Der Stick wird sehr warm
>im Betrieb, es k�nnte durchaus auch ein Temperaturproblem sein, welches
>den Stick so schnell altern l�sst. (Momentan meine Vermutung)
>
>Nun bin ich auf der Suche nach schnellen, und f�r die obige Anwendung
>lange Haltbarkeit geeignete USB Sticks mit ca. 4GB.
>
Ich habe einen von disk2go und der Typ heisst PURE II
das ist ein SLC nand drin, schnell ist es durchaus und wear levelling
haben absolut alle, nur fragt sich wie gut und wie genau wird es
gemacht. (Dynamic oder auch static wear levelling etc)
>
>+ Swap (Auslagerungsdatei oder wie es bei MS heisst) war urspr�nglich
>auch auf dem Stick und wurde nun deaktiviert. Ich k�nnte mir vorstellen,
>dass dadurch viele Schreibzugriffe entstanden sind.
ja , ich habe linux in so einem Betrieb, den swap mussten wir dort
auch abstellen.
>
>+ Welches Dateisystem ist daf�r geeignet? Unter Linux gibt es ja z.B.
>JFFS2,
ja das w�re schon das richtige, da eben transparent auch auf dem
Flash, aber eben du bist auf win.
>wear leveling verwendet wird? Meiner Meinung nach nicht. Angaben ob
>dynamisches oder statisches oder �berhaupt wear leveling verwendet wird
>gibt es selten.
eben, die Angaben muss man aus den Herstellern m�hsam aussaugen
>
>+ NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
>Flash best�ckt, also er�brigt sich die Frage quasi.
ja, NOR passt da nicht mehr rein.
>
>+ SLC (single level cell) oder MLC (multi level cell)? Die Haltbarkeit
>von MLC wird mit >10.000 cyclen angegeben, bei SLC >100.000, also
>bevorzuge ich SLC auch wegen dem h�heren Datendurchsatz
richtig
wie gesagt versuche es mit disk2go PURE II, sind etwas teurer aber
durchaus gut.
Aber f�r die Anwendung was du beschreibtst, w�rde ich auch was
besseres nehmen, also ein besseres diskonmodule oder solid state
drive. Da ist die wear levelling strategie ganz anders ausgelegt, die
controller haben mehr power und alles ist mehr stabil.
Andreas Weber
> Warum nimmst Du nicht eine kleine SSD? Oder eine kleine Notebook-HD.
> Beides ist doch eher f�r diesen Zweck gebaut worden als ein USB-Stick.
Hab ich unten doch geschrieben. Hast du �berhaupt mein Posting gelesen?
Oder nur die ersten 5 Zeilen?
Andreas Weber
Marcel M�ller wrote:
>
> Andreas Weber wrote:
>> + Kann man Windows XP embedded dazu bringen den write cache zu
>> vergr��ern, bzw. was sind sinnvolle Einstellungen? Laut Link oben
>> reicht es, NTFS zu verwenden.
>
> die Gr��e des Cache ist nicht das Problem. Die Frage ist, wie lange die
> Inhalte darin verweilen, bis sie geschrieben werden. Wenn nichts los ist
> schafft das Dateisystem die normalerweise schnellstm�glich weg.
Macht Linux aber z.B. nicht, dieses sammelt durchaus einige Zeit die
Daten und diese werden dann beim "auswerfen" geschrieben.
> Und 100-Byte Schreibzugriffe je Sekunde sind f�r Flash-RAMs nat�rlich
> nicht so toll.
Klar, aber es gibt wohl Flash-Controller (wie von Transcend Industrial)
die einiges an SDRAM haben und dies auch zwischenspeichern, bis der
Cluster voll ist
>> Macht ein spezielles Dateisystem wie exFAT �berhaupt noch Sinn, wenn
>> wear leveling verwendet wird? Meiner Meinung nach nicht.
>
> Eher deshalb nicht weil kein Dateisystem standardm��ig verhindern wird,
> dass eine Datenbank in ihr DB-File schreibt. Die meisten Datenbanken
> machen sowieso ihr eigenes Caching. Da sind selbst die
> Cache-Einstellungen des Dateisystems Banane. => an den
> Datenbankeinstellungen drehen.
Die Datenbank sieht ja das darunter liegende Dateisystem nicht. Wenn der
Dateisystemtreiber die �nderungen nur im Speicher ausf�hrt und nicht
gleich auf das Speichermedium schreibt, bleibt dies der
Applikationsschicht verborgen.
>> + NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
>> Flash best�ckt, also er�brigt sich die Frage quasi.
>
> Nein, die Frage er�brigt sich nicht. F�r den Einsatzzweck w�re NOR-Flash
> genau das richtige.
Klar, daf�r geeignet sicher, aber nicht zu bekommen als USB Stick...
>> + SLC (single level cell) oder MLC (multi level cell)? Die Haltbarkeit
>> von MLC wird mit >10.000 cyclen angegeben, bei SLC >100.000, also
>> bevorzuge ich SLC auch wegen dem h�heren Datendurchsatz
>
> D�rfte �ber kurz oder lang ebenfalls schwer als USB-Teil zu bekommen sein.
Also SLC findet man durchaus bei den h�herpreisigen USB Flash Speicher.
>> Welches die Sticks wieder kurzzeitig "heilen" kann. Was mich schon
>> sehr wundert, denn entweder sind die Zellen kaputt oder nicht.
>
> Wieso? Es ist ein Block kaputt, nicht der Stick. Aufgrund des
> Wear-Levelings haben die Dinger sowieso einige Reservebl�cke.
Ne, HDTune zeigt ca. 90% der Bl�cke als defekt an, wenn der Stick
ausf�llt. Nach einem Formatieren hat er noch eine nutzbare Kapazit�t von
paar MB. Und Hersteller schweigt sich �ber Onlineverbindung aus. Wenn es
mit wear leveling zu tun hat, sollte das ja zur Laufzeit funktionieren.
Ich habe eher das Gef�hl die haben nen Bug in ihrem dynamischen wear
leveling und die Software macht nen Firmwareupdate oder setzt
irgendwelche Bits zur�ck...
>> Reichelt: OCZUSBR2TDC-4GB (leider kein Datenblatt, auch nach R�ckfrage
>
> Consumerware. Das hatten wir schon.
Klar Consumerware, aber schau dir mal Tests bei heise an, die schreiben
2Jahre lang von /dev/random auf den Stick und noch keine Zellen defekt.
So schlecht muss Consumerware nicht sein...
>> Sieht dort nach DualChannel SLC aus, leider auch 10poliger USB Stecker.
>> (gibts f�r die umgekehrte Richtung Adapter oder m�sste ich da selbst
>> was bauen? 10polig male auf 2x4polig female gibts ja �berall als
>> Slotblende)
>
> Das Problem sollte sich ja l�sen lassen.
Das Problem ist nicht so einfach zu l�sen da extrem wenig Platz in IP67
Geh�use zur verf�gung steht und jede Steckverbindung ist Fehlerquelle
bei den Ersch�tterungen.
> Wie gesagt, Write-Cache vom OS bringt bei der DB nichts.
Ganz sicher?
Gru� von Andy
Dschen Reinecke
Moin Andreas!
Da Du Deinen Einsatz nicht genauer beschreibts kann es sein, da� einige
der von mir angedachten M�glichkeiten nicht passen.
> Eine MSSQL Datenbank l�uft auf einem USB-Stick (4polig, male).
> In die Datenbank werden sek�ndlich etwa 120 Byte geschrieben,
> Lesezugriffe eher selten und azyklisch. OS ist Windows XP embedded,
> Dateisystem ist NTFS, "write cache" ist aktiviert �ber "Explorer,
> Properties, Optimize for Performance" (siehe dazu unten auch den Link zu
> Windows write cache und "Plazebo Einstellungen")
> http://www.uwe-sieber.de/usbstick.html
Aus Erfahrung (Linux-Live-System vom Read-Only USB-Stick, mit RAM-Disk
f�r aktuelle Daten) w�rde ich versuchen die Schreibzugriffe zu
begrenzen. Kannst Du nicht eine RAM-Disk einrichten, die nur beim
Runterfahren den Datenbank-Dump auf den Stick kopiert?
Ich wei� nicht, wie es mit dem maximal adressierbaren Speicher bei einem
WinXP embedded aussieht, also was maximal f�r eine RAM-Disk zur
Verf�gung steht. Weiter k�nnte es Problematisch sein, wenn es nicht bei
jedem Ausschalten genug Zeit vorher gibt, die Daten zu kopieren.
Wenn die RAM-Disk nicht geht, dann k�nntest Du evtl die Datenbank
umgehen und Deine wenigen Bytes als eine Art Datenstrom wegspeichern
(Prinzip Data-Logger). Die Auswertung und die DB-Eintr�ge w�rde dann auf
einem Richtigen System und zu einem sp�teren Zeitpunkt erfolgen. Die
Daten, die man wegspeichert sollten in auf den Flash-Speicher
angepassten H�ppchen aufgeteilt werden.
Die Erfahrung mit als Read-Only gemounteten Sticks, die etwa einmal
t�glich beim Booten lesend genutzt werden (das System kopiert sich auch
in die RAM-Disk) zeigt keine gr��ere Ausfall-Wahrscheinlichkeit, obwohl
die Umgebungsbedingungen eher unfreundlich sind (f�r Dich interessant:
eher Warm).
Ciao Dschen
--
Dschen Reinecke
=== der mit dem Namen aus China ===
Gerrit Heitsch
> "Andreas Weber" <sp...@tech-chat.de> schrieb ...
>> Hallo NG,
>> Momentane Situation:
>> Eine MSSQL Datenbank l�uft auf einem USB-Stick (4polig, male).
>
> Ich finde es mutig.
>
>> "write cache" ist aktiviert �ber "Explorer,
>
> Das finde ich noch mutiger...
>
> Warum nimmst Du nicht eine kleine SSD?
Weil die dasselbe Problem entwickeln duerfte (Ok, haelt vielleicht etwas
laenger). Er schreibt pro Sekunde 120 Bytes. Nehmen wir mal an, die sind
in einem Block. Also muss der Controller pro Schreibvorgang einen
Flash-Block (einige KB bis knapp 1 MB) loeschen und neu schreiben. Das
ergibt pro Tag also mindestens (!) 86400 Loeschzyklen, pro Woche 604800.
Wenn das Filesystem-Daten jedesmal angepasst werden noch mehr. Wenn da
das Wearleveling nicht gut ist sind die 10000 Zyklen schnell weg...
Flash basierte SSDs sind eine nette Idee aber fuer gewisse
Zugriffsmuster nicht wirklich tauglich.
Gerrit
Gerrit Heitsch
>
> Klar, aber es gibt wohl Flash-Controller (wie von Transcend Industrial)
> die einiges an SDRAM haben und dies auch zwischenspeichern, bis der
> Cluster voll ist
Wird bei einem USB-Stick eher nicht ausgenutzt, der muss DAU-tauglich
sein, also Abziehen ohne Warnung abkoennen.
> Ne, HDTune zeigt ca. 90% der Bl�cke als defekt an, wenn der Stick
> ausf�llt.
Sieht nach gleichmaessig abgenutzt aus. Da macht der Controller wohl
doch brauchbares Wearleveling nur ist auch damit irgendwann Ende.
Gerrit
Frank-Christian Krügel
> Hallo NG,
> Momentane Situation:
> Eine MSSQL Datenbank l�uft auf einem USB-Stick (4polig, male).
> In die Datenbank werden sek�ndlich etwa 120 Byte geschrieben,
> Lesezugriffe eher selten und azyklisch. OS ist Windows XP embedded,
> Dateisystem ist NTFS, "write cache" ist aktiviert �ber "Explorer,
> Properties, Optimize for Performance" (siehe dazu unten auch den Link zu
> Windows write cache und "Plazebo Einstellungen")
Ich denke, Ihr verwendet die falschen Werkzeuge. Den
Betriebssystem-Cache k�nnt Ihr nicht so weit kontrollieren, wie Ihr
wollt, und den SQL-Server schon gar nicht.
Mein Vorschlag: SQL-Server rauswerfen, eigene Applikation zum Loggen
schreiben, Datei mit CreateFile() und den Flags FILE_FLAG_NO_BUFFERING
und FILE_FLAG_WRITE_THROUGH �ffnen und die Daten selber so lange
buffern, bis ein Cluster voll ist. Immer nur volle Cluster schreiben und
die Anmerkungen im MSDN zu FILE_FLAG_NO_BUFFERING lesen.
Dann noch den Artikel zu misaligned Partitions lesen:
http://www.ocztechnologyforum.com/forum/showthread.php?t=48309
Wenn Ihr alles so gemacht habt, dann sollten Eure USB-Sticks l�nger
durchhalten.
--
Mit freundlichen Gr��en
Frank-Christian Kr�
Juergen Beisert
> [...]
>> + NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
>> Flash best�ckt, also er�brigt sich die Frage quasi.
>
> Nein, die Frage er�brigt sich nicht. F�r den Einsatzzweck w�re NOR-Flash
> genau das richtige.
Was w�re bei NOR besser?
jbe
Juergen Beisert
> [...]
> + Swap (Auslagerungsdatei oder wie es bei MS heisst) war urspr�nglich
> auch auf dem Stick und wurde nun deaktiviert. Ich k�nnte mir vorstellen,
> dass dadurch viele Schreibzugriffe entstanden sind.
Damit kann man sich jeden Flash-Speicher sehr schnell ruinieren. Abschalten
war also eine gute Idee.
> + Welches Dateisystem ist daf�r geeignet? Unter Linux gibt es ja z.B.
> JFFS2, ich bin aber hier unter Windows XP embedded. Da stehen mir
> NTFS,FAT und exFAT zur Verf�gung.
> exFAT http://www.golem.de/0902/65137.html
> Macht ein spezielles Dateisystem wie exFAT �berhaupt noch Sinn, wenn
> wear leveling verwendet wird? Meiner Meinung nach nicht. Angaben ob
> dynamisches oder statisches oder �berhaupt wear leveling verwendet wird
> gibt es selten.
Da der USB-Stick intern sein 'wear leveling' macht, ist das eingesetzte
Dateisystem egal. Manche meinen noch, man solle auf ein Journaling
Dateisystem verzichten, weil es neben den ben�tigten Daten immer auch noch
die Verwaltungsdaten schreibt.
> + NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
> Flash best�ckt, also er�brigt sich die Frage quasi.
NAND hat einfach eine sagenhafte Datendichte und damit einen tolles
Preis/Leistungsverh�ltnis. NOR wird nur noch eingesetzt, wenn es gar nicht
anders geht.
> + SLC (single level cell) oder MLC (multi level cell)?
Ja. SLC: ein Bit pro Zelle. MLC: bis zu drei Bits pro Zelle. Wenn man nur
ein dummd�deliges ECC f�r MLC verwendet, fliegt einem der Mist ruckzuck
unreparierbar um die Ohren. Ich habe hier Controller die 3 ECC-Bytes pro
512 Datenbytes f�r SLC verwenden und 26 ECC-Bytes pro 512 Datenbytes f�r
MLC. Kleiner Unterschied... Wie das wohl die Billig-USB-Sticks handhaben?
> Die Haltbarkeit
> von MLC wird mit >10.000 cyclen angegeben, bei SLC >100.000, also
> bevorzuge ich SLC auch wegen dem h�heren Datendurchsatz
Ich habe vor kurzem da selber nachrecherchiert. W�hrend um etwa 2004 rum
diese Zahlen/Unterschiede noch verlautbart wurden, kann ich sie in
aktuellen Datenbl�ttern nicht mehr wiederfinden. Auch die MLC werden
inzwischen mit 100.000 Zyklen angegeben.
> [...]
> Also, liebe NG Gemeinde: Hat jemand einen Vorschlag?
> Ich kann mir nicht erkl�ren dass der letzte Speicher so schnell den
> Geist aufgegeben hat wenn heutzutage wear leveling schon Standard ist
> und das Betriebssystem einen write cache hat. Gru� von Andy und TIA
Unter Linux muss man auch bewusst das Nachf�hren der Zugriffzeit abstellen,
sonst wird sogar ein ansonsten ro eingeh�ngtes Flash-Dateisystem st�ndig
beschrieben und f�llt einem irgendwann trotzdem aus ("Ich habe doch gar nix
reingeschrieben!").
Gemein ist, das 'wear leveling' lange Zeit gut funktioniert. Dann fallen
erste Bl�cke aus (bei gro�en Flashes sind das dann gleich 128 oder 256 kiB
pro Block der schlagartig fehlt) und dem 'wear leveling' stehen zur
Lastverteilung weniger Bl�cke als vorher zur Verf�gung. D.h. die dann noch
verbliebenen Bl�cke werden noch h�ufiger belastet und fallen dann noch
schneller aus. Lawineneffekt.
jbe
Gerrit Heitsch
>
> Unter Linux muss man auch bewusst das Nachf�hren der Zugriffzeit abstellen,
> sonst wird sogar ein ansonsten ro eingeh�ngtes Flash-Dateisystem st�ndig
> beschrieben und f�llt einem irgendwann trotzdem aus ("Ich habe doch gar nix
> reingeschrieben!").
Eh, was? Das waere aber ein schwerer Bug im Code. Ein 'ro' gemountetes
Filesystem darf niemals beschrieben werden, nein auch nicht die
Zugriffszeiten.
Ansonsten mountet man eben mit 'noatime' und nimmt ext2 als FS (kein
Journal), das muesste auch eine SSD halbwegs lange halten...
> Gemein ist, das 'wear leveling' lange Zeit gut funktioniert. Dann fallen
> erste Bl�cke aus (bei gro�en Flashes sind das dann gleich 128 oder 256 kiB
> pro Block der schlagartig fehlt) und dem 'wear leveling' stehen zur
> Lastverteilung weniger Bl�cke als vorher zur Verf�gung.
Nein, die Anzahl der Bloecke bleibt gleich, es kommt nur ein
Reserveblock dazu. Alle mir bekannten FS reagieren beleidigt wenn die
Anzahl der verfuegbaren Bloecke mit der Zeit abnimmt.
Ein mit X Bloecken formatiertes FS wird schon mit X-1 Bloecken frueher
oder spaeter Aerger machen.
Gerrit
Stefan Reuther
> Marcel M�ller wrote:
>> Andreas Weber wrote:
>>> + Kann man Windows XP embedded dazu bringen den write cache zu
>>> vergr��ern, bzw. was sind sinnvolle Einstellungen? Laut Link oben
>>> reicht es, NTFS zu verwenden.
>>
>> die Gr��e des Cache ist nicht das Problem. Die Frage ist, wie lange
>> die Inhalte darin verweilen, bis sie geschrieben werden. Wenn nichts
>> los ist schafft das Dateisystem die normalerweise schnellstm�glich weg.
>
> Macht Linux aber z.B. nicht, dieses sammelt durchaus einige Zeit die
> Daten und diese werden dann beim "auswerfen" geschrieben.
Linux sammelt solange, bis jemand 'sync()' sagt, und passiert
normalerweise alle ca. 30 Sekunden.
>>> Macht ein spezielles Dateisystem wie exFAT �berhaupt noch Sinn, wenn
>>> wear leveling verwendet wird? Meiner Meinung nach nicht.
>>
>> Eher deshalb nicht weil kein Dateisystem standardm��ig verhindern
>> wird, dass eine Datenbank in ihr DB-File schreibt. Die meisten
>> Datenbanken machen sowieso ihr eigenes Caching. Da sind selbst die
>> Cache-Einstellungen des Dateisystems Banane. => an den
>> Datenbankeinstellungen drehen.
>
> Die Datenbank sieht ja das darunter liegende Dateisystem nicht. Wenn der
> Dateisystemtreiber die �nderungen nur im Speicher ausf�hrt und nicht
> gleich auf das Speichermedium schreibt, bleibt dies der
> Applikationsschicht verborgen.
Eine Datenbank, die ihr Geld wert ist, wird aber nicht so ignorant mit
dem Dateisystem umgehen, sondern es an gewissen Stellen explizit
anweisen, seine Puffer rauszuschreiben, damit sie wiederum der Anwendung
zusichern kann, dass die geschriebenen Daten auch wirklich geschrieben sind.
>>> + NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
>>> Flash best�ckt, also er�brigt sich die Frage quasi.
>>
>> Nein, die Frage er�brigt sich nicht. F�r den Einsatzzweck w�re
>> NOR-Flash genau das richtige.
>
> Klar, daf�r geeignet sicher, aber nicht zu bekommen als USB Stick...
Tja, warum nun eigentlich USB?
Stefan
Michael Karcher
> > die Größe des Cache ist nicht das Problem. Die Frage ist, wie lange die
> Macht Linux aber z.B. nicht, dieses sammelt durchaus einige Zeit die
> Daten und diese werden dann beim "auswerfen" geschrieben.
wenigstens für das Logfile ein "flush den Cache jetzt!" anfordert.
Und dann werden sowohl Windows wie Linux tatsächlich pro Transaktion
schreiben.
Gruß,
Michael Karcher
Andreas Weber
> Tja, warum nun eigentlich USB?
Hi Stefan,
habe ich oben geschrieben, es gibt nur 2 m�gliche Schnittstellen,
n�mlich USB und Ethernet. Wie oben geschrieben w�re NAS mit
herk�mmlicher Festplatte oder SSD der letzte Ausweg.
Gru� von Andy
Andreas Weber
> Mein Vorschlag: SQL-Server rauswerfen, eigene Applikation zum Loggen
> schreiben, Datei mit CreateFile() und den Flags FILE_FLAG_NO_BUFFERING
Hi Frank, ich geb dir v�llig Recht, dass man sich die Sache so besser
kontrollieren l�sst. Ist aber nicht umsetzbar, da alle Awendungen
momentan die SQL Datenbank verwenden.
> Dann noch den Artikel zu misaligned Partitions lesen:
> http://www.ocztechnologyforum.com/forum/showthread.php?t=48309
Der ist gut, danke f�r den Link. btw: ich habe bei ocz nach Datenbl�tter
gefragt. Ist nur ein:"N�, es gibt keine Datenbl�tter zu dem Stick"
zur�ckgekommen. Gru� von Andy
Marcel Müller
Andreas Weber wrote:
>> die Gr��e des Cache ist nicht das Problem. Die Frage ist, wie lange
>> die Inhalte darin verweilen, bis sie geschrieben werden. Wenn nichts
>> los ist schafft das Dateisystem die normalerweise schnellstm�glich weg.
>
> Macht Linux aber z.B. nicht, dieses sammelt durchaus einige Zeit die
> Daten und diese werden dann beim "auswerfen" geschrieben.
Ja, Linux ist aber auch kein XP Embedded, oder?
>> Und 100-Byte Schreibzugriffe je Sekunde sind f�r Flash-RAMs nat�rlich
>> nicht so toll.
>
> Klar, aber es gibt wohl Flash-Controller (wie von Transcend Industrial)
> die einiges an SDRAM haben und dies auch zwischenspeichern, bis der
> Cluster voll ist
Das ist immer eine gef�hrliche Sache. Wenn der Strom weg ist gehen die
Daten mit ihm. Kurzum, kein Consumerdevice wird sich das ohne relativ
kurzes Zeitlimit erlauben, denn sonst g�be ed genug Dussel, die den
Stick einfach nach einer Weile rausrupfen und im Netz �ber Datenverluste
bei der betreffenden Marke herump�beln.
>> Eher deshalb nicht weil kein Dateisystem standardm��ig verhindern
>> wird, dass eine Datenbank in ihr DB-File schreibt. Die meisten
>> Datenbanken machen sowieso ihr eigenes Caching. Da sind selbst die
>> Cache-Einstellungen des Dateisystems Banane. => an den
>> Datenbankeinstellungen drehen.
>
> Die Datenbank sieht ja das darunter liegende Dateisystem nicht. Wenn der
> Dateisystemtreiber die �nderungen nur im Speicher ausf�hrt und nicht
> gleich auf das Speichermedium schreibt, bleibt dies der
> Applikationsschicht verborgen.
Jo, aber jedes Dateisystem kennt auch eine Write-Through-Option beim
�ffnen einer Datei. Und es d�rfte keine ernstzunehmende DB geben, die
dieses Flag nicht setzt.
>>> + NAND oder NOR Flash? Heutzutage sind fast alle USB Sticks mit NAND
>>> Flash best�ckt, also er�brigt sich die Frage quasi.
>>
>> Nein, die Frage er�brigt sich nicht. F�r den Einsatzzweck w�re
>> NOR-Flash genau das richtige.
>
> Klar, daf�r geeignet sicher, aber nicht zu bekommen als USB Stick...
Ja, schwierig geworden. Alte CF-Karten waren mal NOR-Flash. Aber deren
Ma�einheit war nicht GB.
NOR-Flash hat �brigens auch signifikant kleinere Bl�cke und ist schon
deshalb weniger empfindlich bei kleinen Schreibzugriffen. Daf�r hatten
die alten Biester auch kein Wear-Leveling.
>>> + SLC (single level cell) oder MLC (multi level cell)? Die
>>> Haltbarkeit von MLC wird mit >10.000 cyclen angegeben, bei SLC
>>> >100.000, also bevorzuge ich SLC auch wegen dem h�heren Datendurchsatz
>>
>> D�rfte �ber kurz oder lang ebenfalls schwer als USB-Teil zu bekommen
>> sein.
>
> Also SLC findet man durchaus bei den h�herpreisigen USB Flash Speicher.
Ich schrieb ja "�ber kurz oder lang".
>> Wieso? Es ist ein Block kaputt, nicht der Stick. Aufgrund des
>> Wear-Levelings haben die Dinger sowieso einige Reservebl�cke.
>
> Ne, HDTune zeigt ca. 90% der Bl�cke als defekt an, wenn der Stick
> ausf�llt. Nach einem Formatieren hat er noch eine nutzbare Kapazit�t von
> paar MB.
Nimm mal ein echtes Formatierprogramm. Windows stellt sich da beliebig
dumm an, oder funktioniert der Trick mit der /U-Option noch?
> Und Hersteller schweigt sich �ber Onlineverbindung aus. Wenn es
> mit wear leveling zu tun hat, sollte das ja zur Laufzeit funktionieren.
> Ich habe eher das Gef�hl die haben nen Bug in ihrem dynamischen wear
> leveling und die Software macht nen Firmwareupdate oder setzt
> irgendwelche Bits zur�ck...
Schwer zu sagen. Vielleicht sind auch einfach die internen
Verwaltungsstrukturen im Eimer. Den Punkt mit der Temperatur w�rde ich
auf jeden Fall angehen. Vom der Natur der Sache her ist durchaus mit
einer Halbierung der Lebensdauer bei 10�C mehr zu rechnen.
>>> Reichelt: OCZUSBR2TDC-4GB (leider kein Datenblatt, auch nach R�ckfrage
>>
>> Consumerware. Das hatten wir schon.
>
> Klar Consumerware, aber schau dir mal Tests bei heise an, die schreiben
> 2Jahre lang von /dev/random auf den Stick und noch keine Zellen defekt.
> So schlecht muss Consumerware nicht sein...
Klar. Man wei� es nur nie.
Aber ich sagte ja, dass die Schreibrate von 1 Flash-Block pro Sekunde
vmtl. nicht hinreichend f�r den Tod ist.
>>> Sieht dort nach DualChannel SLC aus, leider auch 10poliger USB Stecker.
>>> (gibts f�r die umgekehrte Richtung Adapter oder m�sste ich da selbst
>>> was bauen? 10polig male auf 2x4polig female gibts ja �berall als
>>> Slotblende)
>>
>> Das Problem sollte sich ja l�sen lassen.
>
> Das Problem ist nicht so einfach zu l�sen da extrem wenig Platz in IP67
> Geh�use zur verf�gung steht und jede Steckverbindung ist Fehlerquelle
> bei den Ersch�tterungen.
Sollte man in den Griff bekommen, wenn das Device und die Stecker
beidseitig irgendwo mit Silikon o.�. fixiert sind.
Auf den Stecker am anderen Ende hat man keinen Einfluss? Ich meine ein
USB-Stecker im Ger�teinneren ist doch eher ungew�hnlich.
>> Wie gesagt, Write-Cache vom OS bringt bei der DB nichts.
>
> Ganz sicher?
Jo. Wie hoch muss den die Ausfallsicherheit sein? Sonst lege doch mal
das Transaktionslog der DB in eine RAM-Disk.
Marcel
Alexander Schreiber
Sehr ... mutig.
> In die Datenbank werden sekündlich etwa 120 Byte geschrieben,
Oh, oh.
> Lesezugriffe eher selten und azyklisch. OS ist Windows XP embedded,
> Dateisystem ist NTFS, "write cache" ist aktiviert über "Explorer,
> Properties, Optimize for Performance" (siehe dazu unten auch den Link zu
> Windows write cache und "Plazebo Einstellungen")
> http://www.uwe-sieber.de/usbstick.html
>
> Momentan verwendeter Stick ist
> idVendor 0x058f Alcor Micro Corp.
> idProduct 0x6387 Transcend JetFlash Flash Drive
> bcdDevice 1.42
> iManufacturer 1 JetFlash
> iProduct 2 Mass Storage Device
> iSerial 3 Y2TG7FHS
>
> Datenblatt zu dem Stick:
> http://www.transcendusa.com/Support/DLCenter/Datasheet/TS4GJFT3.pdf
> Dort steht "Erase Cycles >10,000 times" was auf MLC NAND schließen
> lässt, über wear leveling o.Ä. schweigen sie sich aus.
>
> Problem:
> nach ca. 1 Woche Dauerbetrieb steigt der Speicher mit defekten Sektoren
> aus. Wurde mittlerweile mit 3 Sticks getestet. Der Stick wird sehr warm
> im Betrieb, es könnte durchaus auch ein Temperaturproblem sein, welches
> den Stick so schnell altern lässt. (Momentan meine Vermutung)
Nein, Du killst den Chip. Flashspeicher muss bei Schreibzugriffen einen
komplette erase block loeschen und neu schreiben, auch wenn nur ein
einziges Byte geschrieben wird. Die Groesse der erase blocks liegt IIRC
bei 64 KByte aufwaerts. Mit dem kontiniuerlichen Strom kleiner
Schreibzugriffe triggerst Du _massive_ block rewrites und erreichst
damit relativ schnell das Ende der Lebensdauer des Flashspeichers, da
dieser nur eine begrenzte (wenn auch mittlerweile sehr hohe) Anzahl an
Loesch/Schreibzyklen aushaelt.
> Nun bin ich auf der Suche nach schnellen, und für die obige Anwendung
> lange Haltbarkeit geeignete USB Sticks mit ca. 4GB.
Fuer Dein konkretes Szenario wird sich da vermutlich nichts passendes
finden lassen. Sinnvoller waere IMHO eine Aenderung der
Datenaufzeichnung: nicht MSSQL auf dem USB-Stick laufen lassen, sondern
die Daten im Speicher sammeln und dann regelmaessig in groesseren
Bloecken (alle 10 .. 30 min oder so) als einfaches Logfile oder in
aehnlich einfacher, die Schreibzugriffe minimierender Form, auf den
Stick schreiben. Das setzt natuerlich entsprechend stabile
Stromversorgung/Batterie fuer das Geraet voraus sowie Leerschreiben des
Puffers wenn der Strom zur Neige geht.
> + Swap (Auslagerungsdatei oder wie es bei MS heisst) war ursprünglich
> auch auf dem Stick und wurde nun deaktiviert. Ich könnte mir vorstellen,
> dass dadurch viele Schreibzugriffe entstanden sind.
Swap auf Flash ist auch eine gute Methode, Flashspeicher zu killen.
> Eine Festplatte scheidet wegen Erschütterungen aus, eine SSD mit SATA
> oder IDE ist zu groß und die Schnittstellen dafür nicht vorhanden.
> Einziger anderer Ausweg wäre NAS mit SSD und ans Ethernet hängen.
> Kostengünstig soll das halt auch noch sein.
Kostenguenstig, wenn sowieso schon Windows XP und MS-SQL im Einsatz
sind?
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber
>>
>>+ Swap (Auslagerungsdatei oder wie es bei MS heisst) war ursprünglich
>>auch auf dem Stick und wurde nun deaktiviert. Ich könnte mir vorstellen,
> ja , ich habe linux in so einem Betrieb, den swap mussten wir dort
> auch abstellen.
Hier laeuft auch Linux auf CF-Karte: Ohne Swap und die Dateisysteme sind
mit noatime gemountet.
Alexander Schreiber
> Hallo Marcel,
>
> Marcel Müller wrote:
>>
>> Andreas Weber wrote:
>>> + Kann man Windows XP embedded dazu bringen den write cache zu
>>
>
> Macht Linux aber z.B. nicht, dieses sammelt durchaus einige Zeit die
> Daten und diese werden dann beim "auswerfen" geschrieben.
>
>
> Klar, aber es gibt wohl Flash-Controller (wie von Transcend Industrial)
> die einiges an SDRAM haben und dies auch zwischenspeichern, bis der
> Cluster voll ist
Das duerfte aber nicht in den ueblichen USB-Sticks verbaut sein.
>>> Macht ein spezielles Dateisystem wie exFAT überhaupt noch Sinn, wenn
>>> wear leveling verwendet wird? Meiner Meinung nach nicht.
>>
>> Eher deshalb nicht weil kein Dateisystem standardmäßig verhindern wird,
>> dass eine Datenbank in ihr DB-File schreibt. Die meisten Datenbanken
>> machen sowieso ihr eigenes Caching. Da sind selbst die
>> Cache-Einstellungen des Dateisystems Banane. => an den
>> Datenbankeinstellungen drehen.
>
> Die Datenbank sieht ja das darunter liegende Dateisystem nicht. Wenn der
> Dateisystemtreiber die Änderungen nur im Speicher ausführt und nicht
> gleich auf das Speichermedium schreibt, bleibt dies der
> Applikationsschicht verborgen.
Eine vernuenftige Datenbank, die ACID garantiert, schert sich nicht um
den Schreibcache des Betriebssystems, sondern synced die Daten auf Disk
bevor die Transaktion zurueckkommt. Der MS Performance Support wollte
uns allerdings vor ein paar Jahren mal erzaehlen, das MS-SQL das nicht
mache ...
Klaus Rotter
> Hallo NG,
> Momentane Situation:
> Eine MSSQL Datenbank l�uft auf einem USB-Stick (4polig, male).
> In die Datenbank werden sek�ndlich etwa 120 Byte geschrieben,
> Lesezugriffe eher selten und azyklisch. OS ist Windows XP embedded,
> Dateisystem ist NTFS, "write cache" ist aktiviert �ber "Explorer,
> Properties, Optimize for Performance" (siehe dazu unten auch den Link zu
> Windows write cache und "Plazebo Einstellungen")
> http://www.uwe-sieber.de/usbstick.html
Kannst du nicht eine RAM-Disk unter XP embedded einrichten und die
Datenbank in der RAM-Disk laufen lassen? Dann wird alle x Minuten die
Datenbank auf den USB Stick kopiert. Zur Not den Rechner mit
entsprechend RAM ausstatten. 4 GB?
--
Klaus Rotter * klaus at rotters dot de * www.rotters.de
Andreas Weber
> Er schreibt pro Sekunde 120 Bytes. Nehmen wir mal an, die sind
> in einem Block. Also muss der Controller pro Schreibvorgang einen
> Flash-Block (einige KB bis knapp 1 MB) loeschen und neu schreiben. Das
> ergibt pro Tag also mindestens (!) 86400 Loeschzyklen, pro Woche 604800.
Gehen wir von 16kB Block aus, dann darfst du nicht vergessen, dass nach
ca. 140 Schreibvorg�ngen der Block voll ist und der n�chste genommen wird...
Es ist ja nicht so, dass Daten immer nur ge�ndert werden, es kommen ja
auch noch neue hinzu was dazu f�hrt dass selbst ohne wear leveling die
Zellen nicht zu oft gel�scht werden.
Gru� von Andy
Andreas Weber
> Ein mit X Bloecken formatiertes FS wird schon mit X-1 Bloecken frueher
> oder spaeter Aerger machen.
exFAT soll wohl genau darauf auch R�cksicht nehmen.
Gru� Andy
Andreas Weber
> Nein, Du killst den Chip. Flashspeicher muss bei Schreibzugriffen einen
> komplette erase block loeschen und neu schreiben, auch wenn nur ein
> einziges Byte geschrieben wird. Die Groesse der erase blocks liegt IIRC
> bei 64 KByte aufwaerts. Mit dem kontiniuerlichen Strom kleiner
> Schreibzugriffe triggerst Du _massive_ block rewrites und erreichst
> damit relativ schnell das Ende der Lebensdauer des Flashspeichers, da
> dieser nur eine begrenzte (wenn auch mittlerweile sehr hohe) Anzahl an
> Loesch/Schreibzyklen aushaelt.
Alexander, danke für die Antwort, aber denk doch bitte nochmal genau
drüber nach: Selbst wenn der Controller kein wear leveling unterstützt,
das OS keinen WriteCahce hat/nutzt und die 120Bytes wirklich sekündlich
geschrieben wird, dann wird ein 64kB Block 533mal gelöscht und wieder
beschrieben, bis der nächste Block dran ist. Sollte eine flash Block
durchaus ab können.
> Swap auf Flash ist auch eine gute Methode, Flashspeicher zu killen.
Ist mir doch alles klar. Alexander, ich hab mich mit der Materie
durchaus beschäftigt und suche paar NEUE Informationen.
> Kostenguenstig, wenn sowieso schon Windows XP und MS-SQL im Einsatz
> sind?
Hersteller des PanelPC liefert eh WindowsXP mit, sind auch nicht ohne zu
bekommen und MSSQL Express (oder wie es mittlerweile heisst) ist mit 4GB
begrenzung kostenlos.
Gruß Andy
Lutz Schulze
In der MSSQL Datenbank selbst werden doch dabei sicher auch noch jedesmal
ein paar Verwaltungsdateien aktualisiert.
Hier sehe ich eher das Problem.
IMHO ist das Konstrukt so ungeeignet f�r Flash.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch f�r Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Geh�use mit 12 Ports f�r Sensoren
Juergen Beisert
> Juergen Beisert wrote:
>
>>
>> Unter Linux muss man auch bewusst das Nachf�hren der Zugriffzeit
>> abstellen, sonst wird sogar ein ansonsten ro eingeh�ngtes
>> Flash-Dateisystem st�ndig beschrieben und f�llt einem irgendwann trotzdem
>> aus ("Ich habe doch gar nix reingeschrieben!").
>
> Eh, was? Das waere aber ein schwerer Bug im Code. Ein 'ro' gemountetes
> Filesystem darf niemals beschrieben werden, nein auch nicht die
> Zugriffszeiten.
Wurde es aber. Vielleicht ist das inzwischen anders (sogar der Superblock
wird bei einem ro eingeh�ngten Dateisystem geschrieben. Zumindest war vor
ein paar Tagen eine Mail mit Patch auf LKML die genau das versuchte
abzuschalten).
> Ansonsten mountet man eben mit 'noatime'
Genau das tue ich ja auch. ;-)
>> Gemein ist, das 'wear leveling' lange Zeit gut funktioniert. Dann fallen
>> erste Bl�cke aus (bei gro�en Flashes sind das dann gleich 128 oder 256
>> kiB pro Block der schlagartig fehlt) und dem 'wear leveling' stehen zur
>> Lastverteilung weniger Bl�cke als vorher zur Verf�gung.
>
> Nein, die Anzahl der Bloecke bleibt gleich, es kommt nur ein
> Reserveblock dazu. Alle mir bekannten FS reagieren beleidigt wenn die
> Anzahl der verfuegbaren Bloecke mit der Zeit abnimmt.
Bl�cke != Sektoren. Wenn ich von Bl�cken spreche meine ich die interne
Flash-Speicher-Organisation. Ansonsten wird in einem solchen USB-Stick ein
auf Sektoren basiertes Ger�t emuliert (jetzt hast Du Deine Sektoren). Und an
der Stelle setzt auch das "wear leveling" an. Und das versucht dann solange
es irgend geht aus den zur Verf�gung stehenden Flash-Bl�cken die ben�tigten
Sektoren bereitzustellen.
Es mag aber sein, dass dieses Verhalten nur f�r "wear leveling"-Systeme
gilt, die "wissen" welche Sektoren in Benutzung sind (also sch�tzenswerte
Daten enthalten) und welche nicht. Ich kannte mal ein "wear
leveling"-System, das im Hintergrund die FAT ausgewertet hat, um zu wissen,
welche emulierten Sektoren �berhaupt in Benutzung sind (um den gesamten
Prozess zu optimieren).
jbe
Andreas Weber
> IMHO ist das Konstrukt so ungeeignet f�r Flash.
Hi Lutz, bedeutet im Umkehrschluss (Da das System mit DB nicht ge�ndert
werden kann) ein NAS mit herk�mmlicher Festplatte, oder?
Gru� von Andy
Otto Sykora
wir hatten am anfang ganz konservativ eine swap partition drauf und
daran sind die dinger dann gestorben. ohne jeden swap , auch kein
swapfile, halten die viel l�nger und zwar auch mit ext3.
Frank-Christian Krügel
> Frank-Christian Kr�gel wrote:
>
>> Mein Vorschlag: SQL-Server rauswerfen, eigene Applikation zum Loggen
>> schreiben, Datei mit CreateFile() und den Flags FILE_FLAG_NO_BUFFERING
>
> Hi Frank, ich geb dir v�llig Recht, dass man sich die Sache so besser
> kontrollieren l�sst. Ist aber nicht umsetzbar, da alle Awendungen
> momentan die SQL Datenbank verwenden.
Dann m��t Ihr die Anwendungen eben entsprechend umschreiben. Sonst wird
das nix mit flash-basierten Speichermedien.
Alternativen w�ren Speichermedien mit batteriegepuffertem SRAM oder mit
F-RAM (ferroelektrisch, siehe www.ramtron.com).
Thomas 'Tom' Malkus
>
> Hi Frank, ich geb dir vï¿œllig Recht, dass man sich die Sache so besser
> kontrollieren lï¿œsst. Ist aber nicht umsetzbar, da alle Awendungen
Ich verwende unter Linux mit FAT Dateisystem auf SD-Karte sqlite.
Die Schreibzugriffe sind zwar nicht dauernd in dem Umfang wie bei
Dir, aber mehrfach am Tag kommt da auch gut was zusammen. sqlite
gibt es auch fￜr Windows, soweit ich weiￜ gibt es auch ein paar
Libs mit Wrapper Funktionen um das simpelst anzusprechen. Der Vorteil
bei sqlite ist das fein einstellbare Verhalten bezï¿œglich Caching.
Ich habe zwar ab und an auch Ausfï¿œlle, aber nicht unter < 1Jahr und
in der Anleitung steht, dass die SD-Karten mindestens jï¿œhrlich gegen
neue auszutauschen sind. Aber auch mit SD-Karten gibt es Unterschiede,
die Sandisk Ultra II ist hervorragend, zur Zeit verwende ich ï¿œber-
wiegend Industriekarten bezogen bei Glyn.
73 de Tom
--
DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Lutz Schulze
>> IMHO ist das Konstrukt so ungeeignet f�r Flash.
>
> Hi Lutz, bedeutet im Umkehrschluss (Da das System mit DB nicht ge�ndert
> werden kann) ein NAS mit herk�mmlicher Festplatte, oder?
Ja, allerdings bin ich mir bei obiger Aussage nicht 100% sicher.
Vielleicht kann sich noch jemand aussern der da mehr praktische Erfahrung
hat, eventuell �bersehe ich da auch was.
Marcel Müller
h�here Schreibzyklenzahl, kleinere Blockgr��e und (hier nicht relevant)
hohe Schreibgeschwindigkeit. Aber in GB-Regionen ist das schon eher
teuer und vor allem kaum zu bekommen. Also muss SLC-NAND reichen. Das
kriegt man noch.
Marcel
Alex Wenger
> + Kann man Windows XP embedded dazu bringen den write cache zu
> vergrößern, bzw. was sind sinnvolle Einstellungen? Laut Link oben reicht
> es, NTFS zu verwenden.
schau Dir mal den ewfmgr für WindowsXP Embedded an. Damit kannst du
bestimmen wann auf das Flash geschrieben wird. Bei mir hat das
insbesondere die Geschwindigkeit deutlich erhöht.
Irgendwo im Autostart sollte dann ein ewfmgr c: -commit stehen
damit Änderungen einen Neustart überleben.
-Alex
Gerrit Heitsch
> Am Wed, 07 Oct 2009 08:48:37 +0200 schrieb Andreas Weber:
>
>>> Er schreibt pro Sekunde 120 Bytes. Nehmen wir mal an, die sind
>>> in einem Block. Also muss der Controller pro Schreibvorgang einen
>>> Flash-Block (einige KB bis knapp 1 MB) loeschen und neu schreiben. Das
>>> ergibt pro Tag also mindestens (!) 86400 Loeschzyklen, pro Woche 604800.
>> Gehen wir von 16kB Block aus, dann darfst du nicht vergessen, dass nach
>> ca. 140 Schreibvorg�ngen der Block voll ist und der n�chste genommen wird...
>> Es ist ja nicht so, dass Daten immer nur ge�ndert werden, es kommen ja
>> auch noch neue hinzu was dazu f�hrt dass selbst ohne wear leveling die
>> Zellen nicht zu oft gel�scht werden.
>
> In der MSSQL Datenbank selbst werden doch dabei sicher auch noch jedesmal
> ein paar Verwaltungsdateien aktualisiert.
>
> Hier sehe ich eher das Problem.
>
> IMHO ist das Konstrukt so ungeeignet f�r Flash.
Umgekehrt... Flash ist als echter Ersatz fuer eine HD nicht geeignet.
Schaun mer mal wie lange die heute verkauften SSDs im Serverbetrieb
wirklich halten...
Gerrit
Gerrit Heitsch
FAT will man aber nicht mehr benutzen und was ist, wenn der Block mit
Daten belegt war?
Gerrit
Gerrit Heitsch
> Gerrit Heitsch wrote:
>
>> Juergen Beisert wrote:
>>
>>> Unter Linux muss man auch bewusst das Nachf�hren der Zugriffzeit
>>> abstellen, sonst wird sogar ein ansonsten ro eingeh�ngtes
>>> Flash-Dateisystem st�ndig beschrieben und f�llt einem irgendwann trotzdem
>>> aus ("Ich habe doch gar nix reingeschrieben!").
>> Eh, was? Das waere aber ein schwerer Bug im Code. Ein 'ro' gemountetes
>> Filesystem darf niemals beschrieben werden, nein auch nicht die
>> Zugriffszeiten.
>
> Wurde es aber. Vielleicht ist das inzwischen anders (sogar der Superblock
> wird bei einem ro eingeh�ngten Dateisystem geschrieben.
Das waere aber fatal, vor allem wenn man ein Software-RAID1 hat und
davon nach einem Boot von Netz oder CD nur eine Seite 'ro' mountet um
was nachzusehen. Danach waere das RAID inkonsistent und du hast dann
viel Spass...
Und ja, solche ro-mounts einer Haelfte eines RAID1 kommen vor.
> Bl�cke != Sektoren. Wenn ich von Bl�cken spreche meine ich die interne
> Flash-Speicher-Organisation. Ansonsten wird in einem solchen USB-Stick ein
> auf Sektoren basiertes Ger�t emuliert (jetzt hast Du Deine Sektoren). Und an
> der Stelle setzt auch das "wear leveling" an. Und das versucht dann solange
> es irgend geht aus den zur Verf�gung stehenden Flash-Bl�cken die ben�tigten
> Sektoren bereitzustellen.
Was sich das Wear-Leveling uebrigens irgendwo merken muss. Wo
eigentlich? Im Flash? Hm... koennte zu Problemen fuehren.
> Es mag aber sein, dass dieses Verhalten nur f�r "wear leveling"-Systeme
> gilt, die "wissen" welche Sektoren in Benutzung sind (also sch�tzenswerte
> Daten enthalten) und welche nicht.
Das koennen sie gar nicht. Speziell beim Einsatz eines Crypto-FS sind
immer _alle_ Sektoren/Bloecke belegt, jedenfalls aus der Sicht des
Flash-Controllers. Hier laeuft dann auch das teilweise implementierte
TRIM-Kommando ins Leere. Schliesslich soll bei einem solchen FS nichtmal
erkennbar sein was Daten und was freier Platz ist.
Gerrit
Stefan Engler
> Andreas Weber schrieb:
>
> Moin Andreas!
>
> Da Du Deinen Einsatz nicht genauer beschreibts kann es sein, daß einige
> der von mir angedachten Möglichkeiten nicht passen.
>
> > Eine MSSQL Datenbank läuft auf einem USB-Stick (4polig, male).
> > In die Datenbank werden sekündlich etwa 120 Byte geschrieben,
> > Lesezugriffe eher selten und azyklisch. OS ist Windows XP embedded,
> > Properties, Optimize for Performance" (siehe dazu unten auch den Link zu
> > Windows write cache und "Plazebo Einstellungen")
> >http://www.uwe-sieber.de/usbstick.html
>
> für aktuelle Daten) würde ich versuchen die Schreibzugriffe zu
> begrenzen. Kannst Du nicht eine RAM-Disk einrichten, die nur beim
> Runterfahren den Datenbank-Dump auf den Stick kopiert?
>
> Ich weiß nicht, wie es mit dem maximal adressierbaren Speicher bei einem
> WinXP embedded aussieht, also was maximal für eine RAM-Disk zur
> Verfügung steht. Weiter könnte es Problematisch sein, wenn es nicht bei
> jedem Ausschalten genug Zeit vorher gibt, die Daten zu kopieren.
Zur Info den RAM-Disk Treiber gibt es bei MS auch im Quellcode.
Irgendwie
soll bei 32Bit Windows der RAM über 3 GB als RAM-Disk noch nutzbar
sein.
Mann könnte die Daten auch periodisch auf den Stick sichern. Dann sind
halt
nur die Daten von einer Stunde/ einer Minute etc. weg.
Stefan Reuther
> Alexander Schreiber wrote:
>> Nein, Du killst den Chip. Flashspeicher muss bei Schreibzugriffen einen
>> komplette erase block loeschen und neu schreiben, auch wenn nur ein
>> einziges Byte geschrieben wird. Die Groesse der erase blocks liegt IIRC
>> bei 64 KByte aufwaerts. Mit dem kontiniuerlichen Strom kleiner
>> Schreibzugriffe triggerst Du _massive_ block rewrites und erreichst
>> damit relativ schnell das Ende der Lebensdauer des Flashspeichers, da
>> dieser nur eine begrenzte (wenn auch mittlerweile sehr hohe) Anzahl an
>> Loesch/Schreibzyklen aushaelt.
>
> Alexander, danke für die Antwort, aber denk doch bitte nochmal genau
> drüber nach: Selbst wenn der Controller kein wear leveling unterstützt,
> das OS keinen WriteCahce hat/nutzt und die 120Bytes wirklich sekündlich
> geschrieben wird, dann wird ein 64kB Block 533mal gelöscht und wieder
> beschrieben, bis der nächste Block dran ist. Sollte eine flash Block
> durchaus ab können.
Solange wir nicht wissen, wie der Flash-Controller genau funktioniert,
ist jegliche Spekulation albern und zwecklos. (Und selbst wenn man das
oberlehrerhafte "denk noch mal darüber nach" befolgt, kommt man beim
Schreiben von 120 Bytes in eine _Datenbank_ nicht auf 533 Schreib-
operationen pro Block, weil die Datenbank ja auch sowas wie eigene
Metadaten mitführt, und nicht einfach stumpf alles hintereinander schreibt.)
Ein guter Wear-Leveling-Algorithmus wird, wenn er vom Betriebssystem den
Auftrag bekommt, einen Block (i.a. 512 Bytes) zu schreiben, eine neue
Page bzw. Partial Page im Flash schreiben (je nach Typ heutzutage 512
bis 4096 Bytes). Er muss dann nur irgendwo separat speichern, wo er den
Block abgelegt hat. Dazu dienen die Spare-Daten, die NAND-Flash extra
dafür anbietet. Vorteil: schnell und zuverlässig. Nachteil: komplex,
insbesondere bei großen Speichern, braucht Kompaktierung.
Ein schlechter (bzw. nicht vorhandener) Wear-Leveling-Algorithmus wird
sich das Mitführen der Belegungsinformationen sparen wollen und macht
aus dem Schreibauftrag ein read/erase/write eines ganzen Flashblocks
(heutzutage so 128..512k). Vorteil: simpel. Nachteil: unzuverlässig und
tötet den Flash.
Genaue Informationen darüber, was in realen USB-Sticks so abgeht,
bekommt man nicht so einfach, aber von dem, was ich so aufgeschnappt
habe, wird beides sowie beliebige Kombinationen davon durchaus gemacht;
es soll sogar welche geben, die darauf optimiert sind, mit FAT befüllt
zu werden.
Wenn wir den Optimalfall annehmen, dass der erste Algorithmus verwendet
wird, und dazu annehmen, dass die Datenbank drei Schreibzugriffe pro
SQL-Insert generiert, wären das z.B. 3x512 Bytes / Sekunde, das füllt
einen 128k-Flashblock in knapp anderthalb Minuten. Wenn der Wear-
Leveling-Pool z.B. 1024 Flashblöcke enthält, reicht das ziemlich genau
einen Tag. Danach würden das erste Mal Daten kompaktiert und dazu
Flashblöcke gelöscht. Damit reicht NAND-Flash ewig.
Wenn der Stick natürlich Variante 2 anwendet, ist er nach ein, zwei
Tagen breit. Nur steht das eben nicht drauf.
Stefan
Gerrit Heitsch
>
> Wenn wir den Optimalfall annehmen, dass der erste Algorithmus verwendet
> wird, und dazu annehmen, dass die Datenbank drei Schreibzugriffe pro
> SQL-Insert generiert, wären das z.B. 3x512 Bytes / Sekunde, das füllt
> einen 128k-Flashblock in knapp anderthalb Minuten.
Die Eintraege in der FAT nicht vergessen... Jeder Schreibzugriff in die
Datei generiert auch ein paar in die FAT damit die Datei nachher wieder
gefunden wird und ihre Metadaten stimmen.
Gerrit
Stefan Reuther
Die FAT wird nur angefasst, wenn die Datei tatsächlich einen Cluster
wächst. Beim Schreiben eines 120-Byte-Datensatzes kommt das eher selten
vor. Allerdings bleibt noch der Verzeichniseintrag, der Größe und
Modifizierungszeit enthält. Allerdings wächst zum einen eine Datenbank
nicht mit jedem geschriebenen Datensatz (weil das DBMS in größeren
Häppchen vorallokiert), zum anderen aktualisiert Windows das m.W. nur
beim Schließen der Datei.
Aber ansonsten stimmt's schon: 3 Schreibzugriffe ist vermutlich recht
optimistisch geschätzt (gedacht in etwa: Transaktionsanfang, Operation,
Transaktionsende).
Ich kann ja morgen mal schauen, was sqlite auf meinem Flash so macht :-)
Stefan
Andreas Weber
betrifft die Angabe "10.000 erase cycles" die Zyklen pro Zelle/Block
oder den kompletten Speicher?
Von wikipedia:
http://en.wikipedia.org/wiki/Wear_levelling
EEPROM and flash memory media have individually erasable segments, each
of which can be put through a limited number of erase cycles before
becoming unreliable. This is usually around 1000 cycles but many flash
devices have one block with a specially extended life of 100,000+ cycles
that can be used by wear levelling controllers.
Fragend, Gru� Andy
Michael Schwingen
> betrifft die Angabe "10.000 erase cycles" die Zyklen pro Zelle/Block
> oder den kompletten Speicher?
ï¿œblicherweise pro erase unit / sektor.
cu
Michael
Ralph A. Schmid, dk5ras
>Hab ich unten doch geschrieben. Hast du �berhaupt mein Posting gelesen?
>Oder nur die ersten 5 Zeilen?
Verwende eine CF-Karte mit definierten Eigenschaften in einem
USB-Adapter...
-ras
--
Ralph A. Schmid
http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
Ralph A. Schmid, dk5ras
>Umgekehrt... Flash ist als echter Ersatz fuer eine HD nicht geeignet.
Ooch, durchaus, wenn man es richtig angeht.
>Schaun mer mal wie lange die heute verkauften SSDs im Serverbetrieb
>wirklich halten...
Wir haben nach vier bis f�nf Jahren die ersten Totalausf�lle von
dauernd beschriebenen CFs, aber nur Einzelf�lle bisher, bei
dreistelliger Anzahl an GEr�ten.
Jörg Schneide
> Lutz Schulze wrote:
>
>> IMHO ist das Konstrukt so ungeeignet f�r Flash.
Glaub ich auch.
> Hi Lutz, bedeutet im Umkehrschluss (Da das System mit DB nicht ge�ndert
> werden kann) ein NAS mit herk�mmlicher Festplatte, oder?
> Gru� von Andy
Keine Ahnung ob Du sowas noch irgendwie dazustricken kannst, k�nnte aber helfen:
Wie w�re es mit einem Write-Cache in NV-Ram, z.B. gepuffertes SRAM oder einfacher noch
FRAM (gibts mittlerweile auch Automotive).
Sollte nat�rlich so gross sein das m�glichst selten ins Flash geschrieben wird, also
z.B. 2 Flash-Bl�cke reinpassen, f�r Dateisystemverwaltung und aktueller Datenbereich.
So hat man auch definierte Schreibzeiten, man k�nnte in Verbindung mit einer Unterspannungserkennung
und ausreichender Restlaufzeit das System auch gegen Stromausfall sichern.
Falls ein Schreibvorgang aufs Flash nicht beendet werden konnte wird er halt beim
n�chsten Booten durchgef�hrt, die Daten sind ja noch da.
Ich mache sowas �hnliches mit SD-Karten und On-Board-FRAM, aber relativ low-level,
ohne richtiges Betriebssystem und Dateiverwaltung, da ist das einfach.
Inwieweit das die Schreibzugriffe auf das Flash tats�chlich verringert h�ngt nat�rlich
vom ganzen Drumherum (Dateisystem, Datenbankstruktur) und der M�glichkeit das zu Beeinflussen ab.
Windows-Vista soll Unterst�tzung f�r fertige Medien mit integriertem NV-Cache
eingebaut haben, aber vermutlich geht es dabei eher um Hybrid-Disks.
USB-Sticks mit eingebautem NVRAM-Cache sind mir jedenfalls noch nicht untergekommen.
Ich k�nnte mir vorstellen das man sich sowas auch mit einem Vinculum-Chip auch
relativ einfach selber stricken kann.
J�rg.
Andreas Weber
Hi Michael, davon ging ich bis jetzt auch immer aus. Habe aber
unterschiedliche Aussagen darï¿œber gehï¿œrt. Und die USB Stick Hersteller
schreiben einfach nur "erase cycles" rein... Gruￜ Andy
Andreas Weber
> Andreas Weber wrote:
>> Alexander Schreiber wrote:
>>> Nein, Du killst den Chip.
>> Alexander, danke für die Antwort, aber denk doch bitte nochmal genau
>> drüber nach:
> (Und selbst wenn man das
> oberlehrerhafte "denk noch mal darüber nach" befolgt, kommt man beim
> Schreiben von 120 Bytes in eine _Datenbank_ nicht auf 533 Schreib-
> operationen pro Block, weil die Datenbank ja auch sowas wie eigene
> Metadaten mitführt, und nicht einfach stumpf alles hintereinander schreibt.)
Hi Stefan, danke für das ausführliche Posting. Das "oberlehrerhaft"
interpretierst du hinein, war nicht böse gemeint und du hast mir ja
trotzdem geantwortet :-)
Aber du musst ja zugeben, dass die Rechnung nicht so einfach ist wie von
Alexander angenommen. Außer man geht davon aus, dass die angegebenen
"erase cycles" für den kompletten Stick gelten... Gruß von Andy
Klaus P. Pieper
> Frank-Christian Kr�gel wrote:
>
>> Mein Vorschlag: SQL-Server rauswerfen, eigene Applikation zum Loggen
>> schreiben, Datei mit CreateFile() und den Flags FILE_FLAG_NO_BUFFERING
>
> kontrollieren l�sst. Ist aber nicht umsetzbar, da alle Awendungen
Ist denn da kein Proxy f�r die SQL Datenbank m�glich?
Gru�
Klaus
Stefan Reuther
> Stefan Reuther schrieb:
>> Andreas Weber wrote:
>>> Alexander Schreiber wrote:
>>>> Nein, Du killst den Chip.
>
>>> Alexander, danke für die Antwort, aber denk doch bitte nochmal genau
>>> drüber nach:
>
>> (Und selbst wenn man das
>> oberlehrerhafte "denk noch mal darüber nach" befolgt, kommt man beim
>> Schreiben von 120 Bytes in eine _Datenbank_ nicht auf 533 Schreib-
>> operationen pro Block, weil die Datenbank ja auch sowas wie eigene
>> Metadaten mitführt, und nicht einfach stumpf alles hintereinander
>> schreibt.)
>
> Hi Stefan, danke für das ausführliche Posting. Das "oberlehrerhaft"
> interpretierst du hinein, war nicht böse gemeint und du hast mir ja
> trotzdem geantwortet :-)
Sorry, auf Sätze wie "denk mal darüber nach" und "du hast wohl das
Posting nicht gelesen" bin ich irgendwie allergisch :-)
> Aber du musst ja zugeben, dass die Rechnung nicht so einfach ist wie von
> Alexander angenommen. Außer man geht davon aus, dass die angegebenen
> "erase cycles" für den kompletten Stick gelten... Gruß von Andy
Alexander hat eine Rechnung für den Pessimalfall aufgemacht. Und wenn
wir von Consumerplastik reden, gehe ich mal davon aus, das alle
schlimmen Dinge, die man so bauen kann, auch gebaut werden[1].
Um die Verwirrung zu vervollständigen, hab ich noch mal ein bisschen
experimentiert und gesucht.
"Forensic Data Recovery from Flash Memory"
<http://www.ssddfj.org/papers/SSDDFJ_V1_1_Breeuwsma_et_al.pdf>
Da haben sie mal ein paar (ältere) USB-Sticks zerlegt und teilweise
rausgefunden, wie deren Wearleveling funktioniert.
"Hard disks are dead. Now what?"
<http://www.linuxconf.eu/2007/papers/Engel.pdf>
hat eine schöne kurze Erklärung, wie "SmartMedia" funktioniert. Zum
Thema auch noch diesen Absatz, der es gut zusammenfasst.
# A side-effect of waiting is that the current block would be considered
# invalid if the system crashed. That can have interesting consequences
# to databases calling fsync() and trusting the storage media to
# safeguard the data afterwards. Whether all implementations of such an
# optimisations are sync-safe is unknown and hard to test. As always,
# manufacturers tend to be secretive and consumers are left to hope for
# the best.
Und schließlich noch eine Hausnummer zum Thema Datenbank: sqlite
schreibt bei mir für das Einfügen eines Datensatzes in eine einspaltige
Tabelle reichlich 5 kByte in 12 Schreibzugriffen. Bei MSSQL würde ich
ganz ehrlich deutlich mehr erwarten.
Letztlich wird es darauf hinauslaufen, dass eine Datenbank unter deinen
Rahmenbedingungen auf einem kaufbaren USB-Stick mit FAT-Dateisystem
keinen Spaß machen wird, obwohl NAND-Flash durchaus in der Lage wäre,
das zu stemmen.
Stefan
[1] Ähnliches Thema: Versuch mal gezielt, eine SDHC-Karte zu kaufen, die
CMD42 unterstützt. Laut Standard müssen das alle. Aber da der PC diesen
Befehl nicht nutzt, ist der gerne falsch oder gar nicht implementiert.
Teilweise sogar unterschiedlich in verschiedenen Chargen desselben Typs.
Alexander Schreiber
> Andreas Weber wrote:
>> Stefan Reuther schrieb:
>>> Andreas Weber wrote:
>>>> Alexander Schreiber wrote:
>>>>> Nein, Du killst den Chip.
>>
>> Alexander angenommen. Außer man geht davon aus, dass die angegebenen
>> "erase cycles" für den kompletten Stick gelten... Gruß von Andy
>
> Alexander hat eine Rechnung für den Pessimalfall aufgemacht. Und wenn
Und das war nur fuer das Speichermedium alleine.
> wir von Consumerplastik reden, gehe ich mal davon aus, das alle
> schlimmen Dinge, die man so bauen kann, auch gebaut werden[1].
Oh ja. Es gab zum Beispiel auch Consumer USB Sticks mit 2 GB Kapazitaet,
bei denen nur das erste GB wirklich mit Flash hinterlegt war.
Schreibzugriffe ins zweite GB gingen ins Leere ... dafuer waren
die Sticks sehr billig ;-)
> Und schließlich noch eine Hausnummer zum Thema Datenbank: sqlite
> schreibt bei mir für das Einfügen eines Datensatzes in eine einspaltige
> Tabelle reichlich 5 kByte in 12 Schreibzugriffen. Bei MSSQL würde ich
> ganz ehrlich deutlich mehr erwarten.
Die vorgenannten 120 Byte pro Datensatz sind, so nehme ich an, die
Groesse des Datensatzes wie er per INSERT an die DB uebergeben wird.
Dafuer duerfte die DB mindestens 4 Schreibzugriffe taetigen:
- Transaktion als offen ins Log eintragen
- Daten schreiben (die 120 Byte plus allfaelliges Padding)
- Metadaten aktualisieren
- Transaktion als beendet ins Log eintragen
Davon erfolgen letztlich alle mehr oder weniger synchron (also entweder
mit O_SYNC oder fsync (bzw aequivalentes) nach jedem Schreibzugriff).
Real sind es vermutlich noch mehr.
> Letztlich wird es darauf hinauslaufen, dass eine Datenbank unter deinen
> Rahmenbedingungen auf einem kaufbaren USB-Stick mit FAT-Dateisystem
> keinen Spaß machen wird, obwohl NAND-Flash durchaus in der Lage wäre,
> das zu stemmen.
Allerdings.
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Marte Schwarz
> Oh ja. Es gab zum Beispiel auch Consumer USB Sticks mit 2 GB Kapazitaet,
> bei denen nur das erste GB wirklich mit Flash hinterlegt war.
> Schreibzugriffe ins zweite GB gingen ins Leere ...
Wenn sie denn wenigstens ins Leere gegangen w�ren, die haben munter den
unteren GB Bereich �berschrieben. Solange < 1GB benutzt wird, gehen die
Dinger gut. Man darf eben nur eine 1 GB Partition anlegen. Ich habe aber
nicht getestet, was die interne Logik macht, wenn ein Block ersetzt werden
m�sste und kein Flash mehr da ist...
Marte