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

"Andreas Weber" schrieb ...

Ich finde es mutig.

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

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

Einer pro Sekunde? Eher 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.

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.

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.

Wieso? Es ist ein Block kaputt, nicht der Stick. Aufgrund des Wear-Levelings haben die Dinger sowieso einige Reserveblöcke.

Hersteller Fragen.

Consumerware. Das hatten wir schon.

Jetzt stimmt die Richtung.

Das Problem sollte sich ja lösen lassen.

Wie gesagt, Write-Cache vom OS bringt bei der DB nichts.

Marcel

ja MLC

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)

ja , ich habe linux in so einem Betrieb, den swap mussten wir dort auch abstellen.

ja das wäre schon das richtige, da eben transparent auch auf dem Flash, aber eben du bist auf win.

eben, die Angaben muss man aus den Herstellern mühsam aussaugen

ja, NOR passt da nicht mehr rein.

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.

Hab ich unten doch geschrieben. Hast du überhaupt mein Posting gelesen? Oder nur die ersten 5 Zeilen?

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

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.

Klar, dafür geeignet sicher, aber nicht zu bekommen als USB Stick...

Also SLC findet man durchaus bei den höherpreisigen USB Flash Speicher.

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

Klar Consumerware, aber schau dir mal Tests bei heise an, die schreiben

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.

Ganz sicher?

Gruß von Andy

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.

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

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

Wird bei einem USB-Stick eher nicht ausgenutzt, der muss DAU-tauglich sein, also Abziehen ohne Warnung abkoennen.

Sieht nach gleichmaessig abgenutzt aus. Da macht der Controller wohl doch brauchbares Wearleveling nur ist auch damit irgendwann Ende.

Gerrit

Andreas Weber schrieb:

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:

Wenn Ihr alles so gemacht habt, dann sollten Eure USB-Sticks länger durchhalten.

Damit kann man sich jeden Flash-Speicher sehr schnell ruinieren. Abschalten war also eine gute Idee.

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 hat einfach eine sagenhafte Datendichte und damit einen tolles Preis/Leistungsverhältnis. NOR wird nur noch eingesetzt, wenn es gar nicht anders geht.

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

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.

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

Was wäre bei NOR besser?

jbe

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

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

Linux sammelt solange, bis jemand 'sync()' sagt, und passiert normalerweise alle ca. 30 Sekunden.

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.

Tja, warum nun eigentlich USB?

Stefan

ie lange die=20

ist=20

Ich kann mir aber vorstellen, dass die Datenbank vom Betriebssystem wenigstens f=C3=BCr das Logfile ein "flush den Cache jetzt!" anfordert. Und dann werden sowohl Windows wie Linux tats=C3=A4chlich pro Transaktion schreiben.

Gru=C3=9F, Michael Karcher

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

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.

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

Ja, Linux ist aber auch kein XP Embedded, oder?

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.

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.

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.

Ich schrieb ja "über kurz oder lang".

Nimm mal ein echtes Formatierprogramm. Windows stellt sich da beliebig dumm an, oder funktioniert der Trick mit der /U-Option noch?

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.

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.

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.

Jo. Wie hoch muss den die Ausfallsicherheit sein? Sonst lege doch mal das Transaktionslog der DB in eine RAM-Disk.

Marcel

Sehr ... mutig.

Oh, oh.

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.

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 auf Flash ist auch eine gute Methode, Flashspeicher zu killen.

Kostenguenstig, wenn sowieso schon Windows XP und MS-SQL im Einsatz sind?

Man liest sich, Alex.

Das duerfte aber nicht in den ueblichen USB-Sticks verbaut sein.

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

Man liest sich, Alex.