PandoraSuechtig said:
grond said:
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.
Das ist identisch mit dem, was ich meinte: die physikalische Adresse ist Funktion der logischen Adresse, die Abbildung ist eineindeutig und bijektiv, d.h., Adresspaare werden gebildet.
grond said:
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.
Das meinte ich. s/Block/Byte.
grond said:
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...
Meine Ausführungen beruhen auf der Annahme, dass der Controller wissen kann, ob ein Block im FS belegt ist oder nicht. Ich weiß nicht, ob das so ist. Wenn es nicht so ist, müssten grundsätzlich Daten zwischen Quelle und Ziel ausgetauscht werden, wodurch die Anzahl der Schreibzugriffe erst einmal in der Gesamtbilanz verdoppelt würde. Dann bliebe höchstens, besonders aktive Blocks festzustellen und nach einer bestimmten Anzahl Schreibzugriffe mit einem anderen Block zu tauschen. Dazu würde wohl eine Art "history" am einfachsten sein.
grond said:
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???
Anfangszustand: {1, 2, 3}, Basiszeiger = 0
erste Verschiebung (erster physikalischer Block wird freigegeben): {4, 2, 3}, Basiszeiger = 1 (der erste physikalische Block rutscht logisch aufgrund der Erhöhung um Anzahl(Blöcke) = 3 nach hinten)
zweite Verschiebung (zweiter physikalischer Block wird freigegeben): {4, 5, 3}, Basiszeiger = 2
Will ich nun in den logischen Block 1 schreiben, muss ich alle Einträge minus den Basiszeiger rechnen und die Resultate mit der gewünschten logischen Adresse vergleichen. Da wir hier über Hardware reden, wäre das nahezu beliebig parallelisierbar. Allerdings für eine Blockgröße von 512 Bytes nicht praktisch realisierbar. Da müsste man schon mit größeren Blöcken arbeiten.
