langlebige und schnelle USB Sticks (NAND SLC mit wear leveling)

Hier laeuft auch Linux auf CF-Karte: Ohne Swap und die Dateisysteme sind mit noatime gemountet.

Man liest sich, Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
Reply to
Alexander Schreiber
Loading thread data ...

Andreas Weber schrieb:

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
Reply to
Klaus Rotter

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

Reply to
Andreas Weber

exFAT soll wohl genau darauf auch Rücksicht nehmen. Gruß Andy

Reply to
Andreas Weber

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.

Ist mir doch alles klar. Alexander, ich hab mich mit der Materie durchaus beschäftigt und suche paar NEUE Informationen.

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

Reply to
Andreas Weber

Am Wed, 07 Oct 2009 08:48:37 +0200 schrieb Andreas Weber:

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 
 Click to see the full signature
Reply to
Lutz Schulze

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).

Genau das tue ich ja auch. ;-)

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

Reply to
Juergen Beisert

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

Reply to
Andreas Weber

ja ohne swap geht es.

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.

Reply to
Otto Sykora

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

formatting link

--
Mit freundlichen Grüßen

Frank-Christian Krügel
Reply to
Frank-Christian Krügel

Andreas Weber meinte:

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
Reply to
Thomas 'Tom' Malkus

Am Wed, 07 Oct 2009 11:06:43 +0200 schrieb Andreas Weber:

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.

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im 
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin 
 Click to see the full signature
Reply to
Lutz Schulze

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

Reply to
Marcel Müller

Hallo,

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

Reply to
Alex Wenger

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

Reply to
Gerrit Heitsch

FAT will man aber nicht mehr benutzen und was ist, wenn der Block mit Daten belegt war?

Gerrit

Reply to
Gerrit Heitsch

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.

Was sich das Wear-Leveling uebrigens irgendwo merken muss. Wo eigentlich? Im Flash? Hm... koennte zu Problemen fuehren.

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

Reply to
Gerrit Heitsch

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

Reply to
Stefan Reuther

u
m

ei

Zur Info den RAM-Disk Treiber gibt es bei MS auch im Quellcode. Irgendwie soll bei 32Bit Windows der RAM =FCber 3 GB als RAM-Disk noch nutzbar sein.

Mann k=F6nnte die Daten auch periodisch auf den Stick sichern. Dann sind halt nur die Daten von einer Stunde/ einer Minute etc. weg.

Reply to
Stefan Engler

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

Reply to
Gerrit Heitsch

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.