Kleines Weihnachtsupdate von Craig

[PandoraSuechtig]

MTBF beschreibt den Zeitwert zwischen 2 Ausfällen. Das hat zwar was mit Zuverlässigkeit aber nichts mit Lebensdauer oder, für den Servereinsatz entscheidend, mit der Zeit bis zum ersten Ausfall zu tun.

Gut bin hier nicht so spezialisiert, aber ist Zuverlaessigkeit nicht eines der Hauptkriterien fuer Servertauglichkeit bzw. 24/7 Einsatz? Und Serverplatten werden immer auch mit einer hoeheren MTBF beworben? Oder meinst du das waer zwar nicht falsch, aber nicht ausreichend, weil auch die Lebenserwartung eine Rolle spielt?

 

[wejp]

Die Algorithmen sind im Controller drin, er kann daher nicht die belegten Bloecke im FS kennen. Und der Controller kann auch keine "physischen" "belegten/unbelegten" Bloecke unterscheiden, bzw. nur vor dem ersten vollstaendigen beschreiben. Schon nach dem ersten vollstaendigen Formatieren waer das aber der Fall. Sie muessten praktisch die Allokation Tables des FS interpretieren... Sie muessen aber FS-unabhaengig funktionieren. ergo tauschen sie beliebige Bloecke aus anstatt nur "noch freie" zu benutzen.

Das ist so nicht ganz richtig. Controller in SD-Karten sind darauf optimiert mit einem FAT-Dateisystem benutzt zu werden. Wie genau die Interna von den Controllern aussehen ist unklar, aber es ist ja bekannt, dass sich das verwenden anderer Dateisysteme nachteilig auf die Lebenserwartung auswirken kann (und das nicht aufgrund von Journaling oder atime-Zugriffen - das Selbe gilt ja auch für andere nicht-Journaling-Dateisysteme). Ob sich dieses "Wissen" des Controllers über FAT darauf beschränkt, wo das Inhaltsverzeichnis liegt, oder ob mehr Details über das Dateisystem genutzt werden ist unklar.

Würde tatsächlich der Inhalt bereitsbeschriebener Zellen umkopiert, um mehr Zellen für das Wear-Leveling zur Verfügung zu haben, würde dadurch die Performance beim Schreiben nochmal deutlich einbrechen. Das wäre nicht gerade optimal, außerdem würden dann pro Schreibvorgang ja sogar in Wirklichkeit möglicherweise zwei statt nur einer Zelle verändert.

Findet auch nicht allzu haufig statt

Wenn der Controller tatsächlich nicht wüsste, was ein benutzter Block und was ein unbenutzter Block wäre, müsste beim Wear-Leveling ja zwangsweise bei JEDEM Schreibzugriff, der Inhalt des des alternativ verwendeten Blocks umkopiert werden. Entweder man verwendet also kein Wear-Leveling (dann erübrigt sich dieses Problem), oder es wird nur sehr selten verwendet. Wäre letzteres der Fall, dürfte Wear-Leveling kaum einen Einfluss auf die Lebensdauer haben. Wird es dagegen häufig verwendet (z.B. für einen Block, der sehr oft beschrieben wird) hätte es wieder massiven Einfluss auf die Performance.

und falls gelegentlich ein einzelner Block mehr geschrieben wird (Verschiebung), macht das nicht die Welt aus. V.a. ist ja gerade die Zugriffszeit solcher Speicher extrem lahm, darin einen Extrasektor zu verstecken... Ich vergesse natuerlich, dass es Flash ist, da werden ganze Bloecke vor dem Schreiben geloescht. Die koennen auch groesser sein. Dies ist dann Embedded und Flash-Memory-Management, ist eine schwarze Magie fuer sich :huh: Da wunder ich mich nich, dass sie Algorithmen geheim halten. Das "dauernd umzuorganisieren" moeglichst klein zu halten und nicht vor jedem Schreiben eine Reorg mit exponentiellem Aufwand durch zu fuehren ist wertvolles Knowhow. Waer cool wenn hier einer aus dem Gebiet etwas aus dem Naehkaestchen plaudern koennte.

Ja, es ist schon gewissermaßen nachvollziehbar, dass das Know-How geheimgehalten wird, um so unwahrscheinlicher ist es, dass jemand darüber hier etwas erzählen wird.

Meine Argumentation laeuft nur darauf hinaus: Wenn der WL Alg. gut funktioniert, muss der Speicher praktisch 10000 mal VOLL beschrieben werden und je schneller die Platten groesser werden, als die Schreibgeschwindigkeit zunimmt, desto laenger dauert ein volles Beschreiben und damit die Zeit bis ein Block zu oft beschrieben wurde bzw. die MTBF. Und fuer die Lebensdauer bzw. Servertauglichkeit einer Festplatte ist die MTBF entscheidend.

Du vergisst bei deiner Rechnung, dass vom WL-Algorithmus Blöcke umkopiert werden müssten, so dass eben nicht mehr 10000 tatsächlich nutzbare Schreibvorgänge je Block übrig bleiben würden.
Für Servertauglichkeit ist eher die reale Lebensdauer entscheidend, statt der MTBF. MTBF ist ja in der Regel ein ziemlicher Fantasiewert, der unter äußerst unrealistischen Bedingungen ermittelt wird.

 

[Jochen3120]

Für Server kann auch Flash eingesetzt werden, allerdings nur bei Statischen read-only Websiten.
In diesem Einsatzfall kann die sogar eine Geschwindigkeitssteigerung bringen, weil man bei Flash nicht wie bei HDD auf Lese-Schreibkopf und Scheibe warten muss.
Bei Browserspielen ist Flash hingegen sehr nachteilig weil ständig geschrieben wird.
Ich bin gerade dabei ein solches Spiel zu entwickeln, wenn man z.B. etwas ausbaut kann dies mehrere Dutzend schreibzugriffe auslösen.

Gruß, Jochen

 

[Anonymous]

Was WL angeht, hilft es, sich zu überlegen, wie das überhaupt praktisch realisiert werden kann. Um eine physikalische Adresse auf einen anderen Block zu mappen, muss es eine Tabelle geben, die Adresspaare beinhaltet, die einander zugeordnet sind. Nun kann man Gift darauf nehmen, dass die Implementation nicht mit einzelnen Bits oder Bytes, sondern mit Potenzen von 2 funktioniert, was sich schlicht am besten implementieren lässt. Zudem würde andernfalls die genannte Zuordnungstabelle wesentlich größer als der vom Flash gebotene Speicher werden, was natürlich unwirtschaftlich wäre. Die Tabelle muss schließlich selbst nichtflüchtig und damit als Flash realisiert sein. Außerdem braucht sie ein Flag, das anzeigt, ob ein Block belegt oder frei ist.

Es werden nun also Blöcke von 2^n Bytes umgemappt. Von solchen Blöcken gibt es 2^m, die Gesamtkapazität des Flashs ist demnach 2^(n+m) Bytes. Die Zuordnungstabelle muss 2^m Einträge enthalten, um die 2^m Blöcke mappen zu können. Die tatsächliche Adresse eines Blocks setzt sich dann so zusammen: %xxxxxxxxxxyyyyyyyy. "x" bedeutet dabei ein Bit, das aus der Zuordnungstabelle gelesen wird, y ein Bit aus der unveränderten Eingangsadresse. Die Anzahl der "x" beträgt m, die Anzahl der "y" ist n. Nun ist es sinnvoll, 2^n mindestens gleich der Blockgröße eines FAT-Dateisystems zu wählen, welche m.W. normalerweise 512 ist. Außerdem funktioniert FAT wohl so, dass es beim Schreiben einer Datei die freien Blöcke der Reihe nach alloziiert, weshalb es auch so gerne fragmentiert. Also muss der WL-Algo eigentlich nur sicherstellen, dass ein gerade freigegebener Block nicht sofort wieder beschrieben wird. Dazu reicht es, den Adresseintrag für den gerade freigewordenen Block so zu verändern, dass er ganz ans Ende der Blockliste rutscht. Damit wird der Zeitabstand bis zu einem erneuten Beschreiben automatisch maximiert. Nun könne man noch nicht-kontinuierliche Adressen benutzen. D.h., es kommt nicht auf den tatsächlichen Wert an, der in der Tabelle gespeichert ist (Adresse (Block 1) + 2 = (Adresse (Block 2) + 1 = Adresse (Block 3)), sondern nur darauf, dass Adresse(Block 1) < Adresse (Block 2) < Adresse (Block 3). Da man Hardware beliebig paralellisieren kann, wäre die Prüfung hierauf kein besonderer Aufwand (vermutlich würde ein Basiszeiger reichen, dessen Wert man von allen Adressen abzieht und der bei jeder Operation erhöht wird, so dass er immer auf den ersten freien Eintrag zeigt), man würde sich aber das Dekrementieren aller Einträge in der Zuordnungstabelle sparen, wenn ein Block auf den letzten Platz der freien Blöcke rutscht. Viel mehr Intelligenz kann man vermutlich in einen WL-Algorithmus nicht reinstecken, ohne dass es zu aufwendig wird...

 

[Fennias Maxim]

Für Server kann auch Flash eingesetzt werden, allerdings nur bei Statischen read-only Websiten.
In diesem Einsatzfall kann die sogar eine Geschwindigkeitssteigerung bringen, weil man bei Flash nicht wie bei HDD auf Lese-Schreibkopf und Scheibe warten muss.

Und was ist mit den Log-Files?

Bei Browserspielen ist Flash hingegen sehr nachteilig weil ständig geschrieben wird.
Ich bin gerade dabei ein solches Spiel zu entwickeln, wenn man z.B. etwas ausbaut kann dies mehrere Dutzend schreibzugriffe auslösen.

Kommt ganz auf die Programmierung drauf an.

 

[Jochen3120]

Und was ist mit den Log-Files?

Log ausschalten...

Kommt ganz auf die Programmierung drauf an.

Irgendwann muss der schon schreiben, man kann nicht alles im RAM ablegen.

Gruß, Jochen

 

[rick0815]

Wofür braucht man mehr als 2 Tasten gleichzeitig?

Frag mal die Emacs-Nutzer.
Ist es wirklich so das die Pandoratastatur nur 2 Tastendruecke gleichzeitig "sehen" kann? Auch die FN/Shift/ALT/CTRL-Tasten bilden da keine Ausnahme?

 

[MaeKeaPott]

Ich finde das ein oder andere Thema was sich jetzt hier aufgetan hat, ist so interessant, das Ihr dem einem eigenen Thread widtmen solltet. Ich hoffe allerdings, das hier noch nicht dichtgemacht wird, weil dadurch, das hier so lange geredet werden durfte, haben sich interessante Themen aufgetan, auf die man vielleicht so nicht gekommen wäre.
Vielen Dank dafür an dieser Stelle!

 

[rick0815]

Ich finde das ein oder andere Thema was sich jetzt hier aufgetan hat, ist so interessant, das Ihr dem einem eigenen Thread widtmen solltet

Ich habe keinen anderen Thread gefunden welcher sich mit dem betaetigen mehrerer Tasten gleichzeitig auseinander setzt. Also mache ich jetzt mal einen auf *allen Mut zusammennehm*

 

[PandoraSuechtig]

Um eine physikalische Adresse auf einen anderen Block zu mappen, muss es eine Tabelle geben, die Adresspaare beinhaltet, die einander zugeordnet sind.

Falsch. Eine einfache sequentielle Liste der physischen Adressen (die (logische Adresse/Blockgrösse[=2^n]) entspricht dem Index in dieser Tabelle) wär die banalste Lösung. Ansonsten dürfe man bei jedem Lesezugriff die Tabelle durchforsten nach dem passenden Adresspaar... Ich glaube hier wird die Idee einer Mapping-Tabelle und einer Free-table ineffizient vermixt. Abgesehen davon würde man keine keypair-Tabelle, sondern zumindest einen Baum verwenden.
Ich kann sogar noch weiter Argumentieren: Es braucht nicht unbedingt eine "Mappingtabelle", Ich kann auch eine Bitmap mit m Bits führen, die ich jeweils XORe mit der Adresse bei einem Zugriff und dies ist dann die reale Adresse. Die Adressumsetzung ist hierbei extrem schnell (nur ein XOR), aber der Algorithmus zum bestimmen welches Bit jetzt am besten gesetzt werden sollte und das Umtauschen der dadurch betroffenen Blöcke ist massiv umständlicher. Bei jedem solchen Algorithmus für Datenstrukturen ist die Frage: Aufwand für READ/INSERT/REMOVE.

Die tatsächliche Adresse eines Blocks setzt sich dann so zusammen: %xxxxxxxxxxyyyyyyyy. "x" bedeutet dabei ein Bit, das aus der Zuordnungstabelle gelesen wird, y ein Bit aus der unveränderten Eingangsadresse.

Blödsinn. Die Adresse des Blocks besteht aus den x, die y addressieren ein bestimmtes Byte im Block.

Dazu reicht es, den Adresseintrag für den gerade freigewordenen Block so zu verändern, dass er ganz ans Ende der Blockliste rutscht. Damit wird der Zeitabstand bis zu einem erneuten Beschreiben automatisch maximiert.

Zögert nur die Fragmentierung hinaus bis einmal 2^(n+m) Bytes (Fassungsvermögen des Mediums) auf das Medium geschrieben wurden. Also eine ziemlich mickrige Verzögerung...

Nun könne man noch nicht-kontinuierliche Adressen benutzen....

Also doch beliebige Fragmentierung?

Basiszeiger reichen, dessen Wert man von allen Adressen abzieht und der bei jeder Operation erhöht wird, so dass er immer auf den ersten freien Eintrag zeigt), man würde sich aber das Dekrementieren aller Einträge in der Zuordnungstabelle sparen, wenn ein Block auf den letzten Platz der freien Blöcke rutscht.

Nun wirds mir unverständlich, genau genommen ergibt es für mich keinen Sinn. Basiszeiger von allen Adressen abziehen, zugleich soll eine Veränderung dieses Basiszeiger aber keine Anpassung aller Einträge zur Folge haben???

Viel mehr Intelligenz kann man vermutlich in einen WL-Algorithmus nicht reinstecken, ohne dass es zu aufwendig wird...

Ich denke schon, v.a. funktionierende Intelligenz... (Sorry, konnte mir das bashen nicht verkneifen)

hmmmm... Die Lösung von Grond ist ziemlich einfach gestrickt, wie das FAT FS und würde in der Realität nicht funktionieren. Es beinhaltet weitere Unstimmigkeiten:

• Wozu ist das "Free"-Bit? Falls der Controller die FAT-Informationen interpretieren kann, findet er die Information für freie Blöcke dort (oder führt die Free-List). Falls er es nicht interpretiert (FS-unabhängig), kann er schon eine einfache vollständige Formatierung nicht von einem sequentiellen Write unterscheiden, würde von da an alle Blöcke als besetzt führen. Und auch die folgende Argumentation macht keinen Sinn: Da seine Blöcke > FAT-Blöcke sind, braucht er Infos welche belegt sind. Denn hierbei bräuchte er Infos WIE STARK diese Blöcke jeweils belegt sind (wieviele FAT-Blöcke in einem solchen Block belegt sind), also mehr als 1 Bit pro Block.
• Die Aussage "Damit wird der Zeitabstand bis zu einem erneuten Beschreiben automatisch maximiert" ist falsch für den Fall, dass ich einen benutzten Block überschreibe. Nur wenn ich jeden Block zuerst lösche, ihn ans Ende der Liste befördere und zum Schreiben einen neuen aus der Liste nutze
• "Rutscht ans Ende der Liste" ?? Wie wird die Liste gehandhabt? Bei jeder Veränderung die ganze Liste shiften? Das wäre nicht grad wenig zum verschieben und wenn zu dem Zeitpunkt der Strom ausfällt, ist die ganze Mappingtabelle futsch.
• Keine Umverteilung für schon lange belegte und sehr selten wieder beschriebene Blöcke definiert.
• Was passiert bei einem Write?? erfolgt das immer nur in den nächsten "freien Block"? Wenn ja, werden bei einem grossteils gefülltem Medium auf dem nur noch auf dem letzten freien Platz ständig Dateien gelöscht und wieder geschrieben werden diese paar Blocks ständig wiederverwertet und schnell an ihr Limit kommen.

 

[PandoraSuechtig]

Das ist so nicht ganz richtig. Controller in SD-Karten sind darauf optimiert mit einem FAT-Dateisystem benutzt zu werden. Wie genau die Interna von den Controllern aussehen ist unklar, aber es ist ja bekannt, dass sich das verwenden anderer Dateisysteme nachteilig auf die Lebenserwartung auswirken kann (und das nicht aufgrund von Journaling oder atime-Zugriffen - das Selbe gilt ja auch für andere nicht-Journaling-Dateisysteme). Ob sich dieses "Wissen" des Controllers über FAT darauf beschränkt, wo das Inhaltsverzeichnis liegt, oder ob mehr Details über das Dateisystem genutzt werden ist unklar.

Mich würde eine Quelle hierfür sehr interessieren!!! Darüber wurde hier übrigens schon früher gestritten: http://www.gp32x.com/board/index.php?showtopic=40549&st=30
Auch dies ist interessant:
http://ask.slashdot.org/article.pl?sid=06/10/19/0455215
Hier diskutiert einer sogar darüber, dass das Schreiben des Flash selber nicht als Transaktion abgesichert war. Mitten im Schreiben unterbrochen produzierte das Flash einen "defekten" Sektor, der erst nach einem neuen beschreiben wieder lesbar war. Dies war dann gerade mit einem Journaling FS kein Problem, weil hier ein solcher nicht fertig geschriebener Sektor sowieso als Frei galt und automatisch nicht gelesen wurde, bis wieder einmal beschrieben. Auch wird diskutiert darüber wie das WL im Controller jede Defragmentierung und jedes WL-fähige FS behindert.

Und mir ist endlich das Killerargument eingefallen warum der Controller die FAT Informationen nicht nutzen kann für WL:
Würde er die Blöcke im FS verschieben und die FAT-Tabelle anpassen würde diese nicht mehr mit dem OS-Cache übereinstimmen. Die Verteilung der Blöcke muss nach aussen vor und nach einer "Umstellung" gleich aussehen. Er muss daher ein internes Mapping führen zwischen der "äusseren/logischen" und der "internen/realen" Verteilung.

Wenn der Controller tatsächlich nicht wüsste, was ein benutzter Block und was ein unbenutzter Block wäre, müsste beim Wear-Leveling ja zwangsweise bei JEDEM Schreibzugriff, der Inhalt des des alternativ verwendeten Blocks umkopiert werden. Entweder man verwendet also kein Wear-Leveling (dann erübrigt sich dieses Problem), oder es wird nur sehr selten verwendet. Wäre letzteres der Fall, dürfte Wear-Leveling kaum einen Einfluss auf die Lebensdauer haben. Wird es dagegen häufig verwendet (z.B. für einen Block, der sehr oft beschrieben wird) hätte es wieder massiven Einfluss auf die Performance.

Ein Replace sollte nur stattfinden, wenn der Block schon zu oft benutzt wurde (usage count pro Block sollte schon vorhanden sein). Bis dahin kann er ruhig öfters beschrieben werden. Das Schreiben auf dem Medium erfolgt ja nicht gleichmässig, sondern gewisse Blöcke werden extrem oft beschrieben, genau diese würden dann z.B. 1000x normal überbeschrieben, dann beim 1001 Write ausgetauscht und der "neue" Block wieder 1000x beschrieben. Wozu bei "Jedem Schreibzugriff" umkopieren???

Du vergisst bei deiner Rechnung, dass vom WL-Algorithmus Blöcke umkopiert werden müssten, so dass eben nicht mehr 10000 tatsächlich nutzbare Schreibvorgänge je Block übrig bleiben würden.

Guter Einwand, das vermindert das Ergebnis dann etwa im Promille Bereich.

Schlussfrage: Spielt Fragmentierung bei Flashmedien überhaupt eine Rolle, da Seekzeiten hier um ein vielfaches kleiner als bei magnetischen Platten sind??

 

[wejp]

Das ist so nicht ganz richtig. Controller in SD-Karten sind darauf optimiert mit einem FAT-Dateisystem benutzt zu werden. Wie genau die Interna von den Controllern aussehen ist unklar, aber es ist ja bekannt, dass sich das verwenden anderer Dateisysteme nachteilig auf die Lebenserwartung auswirken kann (und das nicht aufgrund von Journaling oder atime-Zugriffen - das Selbe gilt ja auch für andere nicht-Journaling-Dateisysteme). Ob sich dieses "Wissen" des Controllers über FAT darauf beschränkt, wo das Inhaltsverzeichnis liegt, oder ob mehr Details über das Dateisystem genutzt werden ist unklar.

Mich würde eine Quelle hierfür sehr interessieren!!!

Ich werde versuchen das wiederzufinden. Ich meine es mal vor längerer Zeit in einer c't gelesen zu haben. Ich muss meine alten c'ts mal danach durchsuchen.

Und mir ist endlich das Killerargument eingefallen warum der Controller die FAT Informationen nicht nutzen kann für WL:
Würde er die Blöcke im FS verschieben und die FAT-Tabelle anpassen würde diese nicht mehr mit dem OS-Cache übereinstimmen. Die Verteilung der Blöcke muss nach aussen vor und nach einer "Umstellung" gleich aussehen. Er muss daher ein internes Mapping führen zwischen der "äusseren/logischen" und der "internen/realen" Verteilung.

So hatte ich es nicht gemeint und es ist so auch höchst wahrscheinlich gar nicht realisiert, wenn der Controller das FS berücksichtigt. Viel mehr kann der Controller die Charakteristiken von FAT nutzen um intelligent Blöcke zu beschreiben. Z.B. könnte der Controller Teile die besonders oft von FAT-FS neu beschrieben werden, häufiger in andere Bereiche schreiben oder der Controller könnte feststellen, welche Blöcke vom FS aktuell nicht benutzt werden und diese bevorzugt für das WL verwenden, da dann nichts umkopiert werden muss. Das darf für das Dateisystem natürlich nicht sichtbar sein, aber für die genannten Beispiele wäre das auch nicht nötig. Die Zuordnung zwischen logischen und physikalischen Adressen des Flash-Speichers muss natürlich immer vor dem FS versteckt werden. Du hast ganz sicher recht damit, dass der Controller niemals das Dateisystem selbst verändern wird. Das bedeutet aber nicht gleich, dass der Controller Wissen über Eigenschaften des FS nicht zu Nutze machen kann.

Ein Replace sollte nur stattfinden, wenn der Block schon zu oft benutzt wurde (usage count pro Block sollte schon vorhanden sein). Bis dahin kann er ruhig öfters beschrieben werden. Das Schreiben auf dem Medium erfolgt ja nicht gleichmässig, sondern gewisse Blöcke werden extrem oft beschrieben, genau diese würden dann z.B. 1000x normal überbeschrieben, dann beim 1001 Write ausgetauscht und der "neue" Block wieder 1000x beschrieben. Wozu bei "Jedem Schreibzugriff" umkopieren???

So war es nicht gemeint. Nicht bei jedem Schreibzugriff, sondern bei jedem Schreibzugriff, der durch WL auf einen anderen Block umgeleitet werden soll, müsste der Inhalt umkopiert werden. Ich vermute mal stark, dass intelligente WL-Algorithmen genau das nicht machen werden (1000 mal beschreiben und ab einem bestimmten Zählerstand einen anderen Block wählen), sondern versuchen werden die Schreibzugriffe möglichst gleichmäßig zu streuen, wenn möglich. Ich vermute auch, dass es keinen Zähler für jeden Block gibt, wie oft dieser beschrieben wurde. Das würde die Performance beim Schreiben ja nochmal deutlich reduzieren, da dieser Zähler bei jedem Schreibzugriff zunächst gelesen und dann wieder geschrieben werden müsste.

Du vergisst bei deiner Rechnung, dass vom WL-Algorithmus Blöcke umkopiert werden müssten, so dass eben nicht mehr 10000 tatsächlich nutzbare Schreibvorgänge je Block übrig bleiben würden.

Guter Einwand, das vermindert das Ergebnis dann etwa im Promille Bereich.

Dass das nur Änderungen im Promillebereich bewirken würde, ist reine Spekulation.

Schlussfrage: Spielt Fragmentierung bei Flashmedien überhaupt eine Rolle, da Seekzeiten hier um ein vielfaches kleiner als bei magnetischen Platten sind??

Fragmentierung sollte genau aus dem von dir genannten Grund so gut wie keine Rolle spielen.

EDIT: Ich habe mir gerade mal den Thread im englischen Forum durchgelesen. Squidge hat in jedem Fall mit zwei Punkten absolut Unrecht: 1) CF-Karten machen auch Wear-Leveling und der Controller ist bei den Karten eingebaut, da die Teile ja nichts anderes als IDE/ATA-Geräte sind.
2) Festplatten haben auch "Wear-Leveling". Jede Festplatte hat einen Reservebereich, der verwendet wird, wenn Bereiche der Platte kaputtgehen. Das kann man sich ja sogar über die SMART-Informationen anzeigen lassen, wie oft das schon passiert ist.

 

[PandoraSuechtig]

So hatte ich es nicht gemeint und es ist so auch höchst wahrscheinlich gar nicht realisiert, wenn der Controller das FS berücksichtigt. Viel mehr kann der Controller die Charakteristiken von FAT nutzen um intelligent Blöcke zu beschreiben. Z.B. könnte der Controller Teile die besonders oft von FAT-FS neu beschrieben werden, häufiger in andere Bereiche schreiben oder der Controller könnte feststellen, welche Blöcke vom FS aktuell nicht benutzt werden und diese bevorzugt für das WL verwenden, da dann nichts umkopiert werden muss.

Gute Idee. Er kann sich das Umkopieren sparen, wenn der Block mit einem getauscht wird, der unter einem freien Sektor lag... Solange der Flash noch nicht allzu voll ist. Wenn du wirklich eine c't hervorkramst wo dies steht... bin ich ruhig :huh:

So war es nicht gemeint. Nicht bei jedem Schreibzugriff, sondern bei jedem Schreibzugriff, der durch WL auf einen anderen Block umgeleitet werden soll, müsste der Inhalt umkopiert werden. Ich vermute mal stark, dass intelligente WL-Algorithmen genau das nicht machen werden (1000 mal beschreiben und ab einem bestimmten Zählerstand einen anderen Block wählen), sondern versuchen werden die Schreibzugriffe möglichst gleichmäßig zu streuen, wenn möglich. Ich vermute auch, dass es keinen Zähler für jeden Block gibt, wie oft dieser beschrieben wurde. Das würde die Performance beim Schreiben ja nochmal deutlich reduzieren, da dieser Zähler bei jedem Schreibzugriff zunächst gelesen und dann wieder geschrieben werden müsste.

Bin ziemlich sicher, dass Blöcke in Flashspeichern Prüfsummen und weitere Informationen inkl. einem WriteCounter beinhalten. Bei Flashspeicher wird immer der ganze Block (gelöscht und dann?) geschrieben, ob er dann bei einem paar kb grossen Block noch die paar Byte anhängt, spielt keine Rolle. Es ist ein Block-Device. Kann hierzu gerne auch Referenzen suchen. Hab noch vage was im Hinterkopf, dass beim Löschen gleichzeit ein Auslesen möglich ist... Aber da bin ich sehr unsicher. Müsste wieder mal tiefer über Flashes nachlesen.
1000 ist vielleicht etwas hoch, aber jede 100 oder mehrere 100 Zugriffe würde sich dann der Controller einen Block zum Austauschen suchen.

Dass das nur Änderungen im Promillebereich bewirken würde, ist reine Spekulation.

Logo. Aber ich spekuliere ja, dass ein Austausch eines Blockes mit einem UsageCounter (angenommen jede 100 wird er ausgetauscht) nur jede paar 1000 Schreibzugriffe (aufs gesamte Medium) erfolgt. Angenommen wir hätten ein 4 GB Flash, 16kb Blöcke, sind 65000 Blöcke. Es bräuchte also allein 65000 Schreibzugriffe um überhaupt alle Blöcke 1x zu beschreiben. Mit einer etwas realeren Zugriffverteilung würde ich immer noch einige Dutzend Schreibzugriffe (Datenbereich) zwischen jedem FAT-Table (die am häufigsten beschriebenen Blöcke) update erwarten. das mal jede 100 macht über 1000 Schreibzugriffe. Also ein Overhead im Promille Bereich. Das war etwa meine Rechnung/Spekulation.
Ich stelle mir aber eine andere Frage: Wenn es irgendwo eine "Mapping"-Table gibt, die ja auch in einigen Blöcken des Flash liegt, werden diese doch viel öfters Upgedatet. Ein Block enthält eine ganze Menge von Mapping-Referenzen auf Blöcke und wird neu geschrieben wenn auch nur eine solche ändert. Daher frage ich mich ob nicht ganze Gruppen von Solchen Blöcken auf einmal geswappt werden? Oder das ganze ist gar nicht so granular sondern in viel grösseren Blöcken segmentiert?

Aber ich denke wir werden uns sowieso nicht einigen bis wir andere Quellen studiert haben. Bis dahin können wir nur spekulieren.

 

[wejp]

Bin ziemlich sicher, dass Blöcke in Flashspeichern Prüfsummen und weitere Informationen inkl. einem WriteCounter beinhalten. Bei Flashspeicher wird immer der ganze Block (gelöscht und dann?) geschrieben, ob er dann bei einem paar kb grossen Block noch die paar Byte anhängt, spielt keine Rolle. Es ist ein Block-Device. Kann hierzu gerne auch Referenzen suchen. Hab noch vage was im Hinterkopf, dass beim Löschen gleichzeit ein Auslesen möglich ist... Aber da bin ich sehr unsicher. Müsste wieder mal tiefer über Flashes nachlesen.
1000 ist vielleicht etwas hoch, aber jede 100 oder mehrere 100 Zugriffe würde sich dann der Controller einen Block zum Austauschen suchen.

Ein paar Byte an jeden Block zusätzlich anzuhängen sollte tatsächlich kein großes Problem darstellen (mal abgesehen von daraus resultierenden "krummen" Blockgrößen), aber der jeweils zusätzlich nötige Lesezugriff ist durchaus nicht zu vernachlässigen. Wenn das tatsächlich ohne Aufwand kombiniert mit einem Löschen realisiert werden kann, wäre es unproblematisch, aber mir ist nicht klar, wie sich das technisch realisieren lassen sollte.

Ich stelle mir aber eine andere Frage: Wenn es irgendwo eine "Mapping"-Table gibt, die ja auch in einigen Blöcken des Flash liegt, werden diese doch viel öfters Upgedatet. Ein Block enthält eine ganze Menge von Mapping-Referenzen auf Blöcke und wird neu geschrieben wenn auch nur eine solche ändert. Daher frage ich mich ob nicht ganze Gruppen von Solchen Blöcken auf einmal geswappt werden? Oder das ganze ist gar nicht so granular sondern in viel grösseren Blöcken segmentiert?

Wie das genau passiert (Größe der getauschten Blöcke etc.) wird einem so genau vermutlich niemand sagen können, da das ja zu den geheimen Parametern der WL-Algorithmen gehört.

Aber ich denke wir werden uns sowieso nicht einigen bis wir andere Quellen studiert haben. Bis dahin können wir nur spekulieren.

Wie gesagt, ich werde mal nach der besagten c't Ausschau halten. Vielleicht finde ich die noch wieder.

 

[PandoraSuechtig]

Vielleicht noch eine Begründung warum ich von UsageCounter/WriteCounter (WC) spreche:
Ich kann nicht bei jedem Schreibzugriff (SZ) auf irgendeinen Block eine zentrale Statistik nachführen (weshalb ich den Vorschlag von Gond für abwegig halte, da sehr praxisfern), denn die ist ja persistent und würde nach 10'000 SZ auf dem Flash diesen einen Block mit den Statistiken schon ans Limit bringen. Also bereits nach der ersten Formatierung des Flashes wäre das Limit erreicht? Natürlich kann man dies intelligent verteilen (zyklisches Schreiben auf ein Set von Blöcken mit inkrementeller ID), trotzdem heisst dies, bei jedem SZ werden im Grunde 2 Blöcke geschrieben (Dazu müsste bei so einem Set von Blöcken jeder gelesen werden bis der mit der neusten ID als der aktuell gültige identifiziert wurde).
Wenn ich nun einen WC verwende, der im Block mit drin ist (paar extrabytes in jedem Block), wird er im normalen SZ mit upgedatet. Und nun der Trick: Nach dem Lesen teste ich
WC % (2^x) == 0 [% = modulo]
(Das wär die effiziente Variante des "jede 100" Tests mit einem vielfachen von 2)
und nur falls true, bemühe ich mich evtl. um ein Replacing und um einen Update des Blocks mit den Statistiken (mapping table, am seltensten benutzte blöcke, usw.). So wird der Teil mit den Statistiken nur selten angefasst.

Hab mal in Wikipedia geguckt.
http://de.wikipedia.org/wiki/Flash-Speicher#Defektmanagement_im_Flash.2FAnsteuerlogik
Hier steht steht sogar etwas von 512Byte Blöcken mit je 64(?)Byte Daten fürs Defektmanagement.

Was mir aber weiterhin eine ungeklärte Frage bleibt: Wie findet man am schnellsten die am wenigsten benutzten Blöcke zum Austauschen? Oder wie kann man die Kandidaten eingrenzen für eine schnelle sequentielle Suche. z.B. nur die nichtbelegten Blöcke im FAT FS durchsuchen?

 

[PandoraSuechtig]

aber der jeweils zusätzlich nötige Lesezugriff ist durchaus nicht zu vernachlässigen. Wenn das tatsächlich ohne Aufwand kombiniert mit einem Löschen realisiert werden kann, wäre es unproblematisch, aber mir ist nicht klar, wie sich das technisch realisieren lassen sollte.

Wie geschrieben habe ich das nur ziemlich vage noch im Hinterkopf. Kann mich da täuschen. Im Wikipedia-Artikel hatte ich grad nichts davon gelesen. Aber Flash liest ja viel schneller, als, dass es schreibt. Und nur die paar Extrabytes zu lesen und dann den ganzen Block zu schreiben, das sollt schon drin liegen.

 

[wejp]

Hab mal in Wikipedia geguckt.
http://de.wikipedia.org/wiki/Flash-Speicher#Defektmanagement_im_Flash.2FAnsteuerlogik
Hier steht steht sogar etwas von 512Byte Blöcken mit je 64(?)Byte Daten fürs Defektmanagement.

64 Byte wären etwas viel im Verhältnis zu den 512 Byte. Es werden eher ~64 Bit sein. Der Teil scheint aber nur für Prüfsummen verwendet zu werden um Bitfehler zu erkennen.

Was mir aber weiterhin eine ungeklärte Frage bleibt: Wie findet man am schnellsten die am wenigsten benutzten Blöcke zum Austauschen? Oder wie kann man die Kandidaten eingrenzen für eine schnelle sequentielle Suche. z.B. nur die nichtbelegten Blöcke im FAT FS durchsuchen?

Ich würde sagen: gar nicht. Genau genommen muss der WL-Algorithmus das nicht tun. Wenn man annimmt, dass angestrebt wird eine möglichst gleichmäßige Abnutzung des Speichers zu erreichen, könnte man einfach zufällig einen beliebigen Block auswählen. Dadurch würde jeder Block im Durchschnitt gleich oft beschrieben werden. Um eine bessere Performance zu erreichen könnte man bei einem bekannten Dateisystem (wie z.B. FAT) die Auswahl auf Blöcke beschränken, die dem Dateisystem als frei bekannt sind. Dazu hält das FS eine Datenstruktur mit freien Blöcken bereit. In dem Fall würde man dann die zufällige Auswahl aus der Liste der freien Blöcke treffen.

Aber Flash liest ja viel schneller, als, dass es schreibt. Und nur die paar Extrabytes zu lesen und dann den ganzen Block zu schreiben, das sollt schon drin liegen.

Ob nur ein paar Bytes oder der ganze Block relevant sind, spielt für den Lesevorgang keine Rolle, weil bei NAND-Flash ja immer blockweise gelesen wird.

 

[PandoraSuechtig]

64 Byte wären etwas viel im Verhältnis zu den 512 Byte. Es werden eher ~64 Bit sein. Der Teil scheint aber nur für Prüfsummen verwendet zu werden um Bitfehler zu erkennen.

Leider ist hier im Artikel keine Referenz angegeben und die Zahl mit einem Fragezeichen angegeben. Und wenn ich schon eine Prüfsumme schreibe, passt auch locker ein WriteCount hinein

könnte man einfach zufällig einen beliebigen Block auswählen. Dadurch würde jeder Block im Durchschnitt gleich oft beschrieben werden. Um eine bessere Performance zu erreichen könnte man bei einem bekannten Dateisystem (wie z.B. FAT) die Auswahl auf Blöcke beschränken, die dem Dateisystem als frei bekannt sind. Dazu hält das FS eine Datenstruktur mit freien Blöcken bereit. In dem Fall würde man dann die zufällige Auswahl aus der Liste der freien Blöcke treffen.

Beim Ersten Verfahren kannst du auch zufällig einen schon oft beschriebenen Block erwischen (ausser du verwendest keinen Counter und machst bei jedem Schreibzugriff ein Ersetzen, das sollte statistisch befriedigend ausfallen). Im zweiten Fall wird nach den ersten Austäuschen die Menge der freien Sektoren im FAT auch auf viele schon oft benutzte Blöcke (da vorher ausgetauscht) verweisen (Und wenn bei jedem Schreibzugriff ausgetauscht wird, währen diese Blöcke schnell "verwässert"). Dazu kommt das Problem des fast vollen Sticks.

 

[Jochen3120]

Da hier ja so oft über das auslesen von FAT diskutiert wird, kommt mir die Frage auf:
Was macht der WL-Controller wenn ich mir ein eigenes FS ausdenke und dies auf den Stick los lasse?

Gruß, Jochen

 

[PandoraSuechtig]

Wejp behauptet: Dann läuft er weniger effizient.
Ich bin sowieso eher dafür, dass der Typ vom FS ignoriert wird.