Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision | ||
dnbd3_fuse_cow [2022/09/08 16:46 CEST] – Lese Anfrage mscherle | dnbd3_fuse_cow [2022/09/09 18:28 CEST] – Threads und Locks mscherle | ||
---|---|---|---|
Zeile 375: | Zeile 375: | ||
</ | </ | ||
- | ===Lese Anfrage=== | + | ===Leseanfrage=== |
Wird eine Lese anfrage gestellt werden alle benötigten " | Wird eine Lese anfrage gestellt werden alle benötigten " | ||
Falls ja werden die daten aus der Daten Datei geladen. Das Offset ist dabei das cow_block_metadata_t Offset plus 4096 * blocknummer im Cow Block. | Falls ja werden die daten aus der Daten Datei geladen. Das Offset ist dabei das cow_block_metadata_t Offset plus 4096 * blocknummer im Cow Block. | ||
Falls das bit im bitfield jedoch 0 ist, gibt es zwei Fälle. Ist das offset kleiner als die Origial Image Größe werden die Daten mit 0 aufegfüllt (die Origial Image Größe Variable kann bei einem truncate die kleiner ist als das uhrprünglich Image weiter reuziert werden). | Falls das bit im bitfield jedoch 0 ist, gibt es zwei Fälle. Ist das offset kleiner als die Origial Image Größe werden die Daten mit 0 aufegfüllt (die Origial Image Größe Variable kann bei einem truncate die kleiner ist als das uhrprünglich Image weiter reuziert werden). | ||
Abdernfalls werden die Daten von dem dnbd3 server geladen. | Abdernfalls werden die Daten von dem dnbd3 server geladen. | ||
+ | Da die Leseanfragen an den dnbd3 server asyncron ausgeführt werden, gibt es eine workCounter variable, die Anzahl der Parallelen anfragen plus der einzelnen lokalen enthält. | ||
+ | Erst wenn diese Variable 0 ist, wird die Fuse-Anfrage beendet. | ||
+ | ===Schreibanfrage=== | ||
+ | Wenn bei einer Schreibanfrage der Anfang oder das Ende nicht mit einem Vielfachen von 4096 übereinstimmt, | ||
+ | Das liegt daran, dass jeder 4096-Byte-Block vollständige Daten benötigt, denn wenn das Bit im Bitfeld für diesen Block gesetzt ist, werden alle Daten lokal gelesen. | ||
+ | Um den Block aufzufüllen, | ||
+ | Liegt er außerhalb der ursprünglichen Imagegröße (weil z.B. das Image größer geworden ist), werden die fehlenden Bytes mit 0 aufgefüllt. | ||
+ | Die Schreibanfrage errechnet aus dem Offset die entsprechenden cow_block_metadata_t. | ||
+ | Wenn die entsprechende cow_block_metadata_t noch nicht existiert, wird sie angelegt. | ||
+ | Die Daten werden in die Datendatei geschrieben, | ||
+ | Dann wird das entsprechende Bit in den Bitfeldern gesetzt und die timeChanged aktualisiert. | ||
+ | Wenn mehr Daten zu schreiben sind, wird die nächste cow_block_metadata_t berechnet und die obigen Schritte werden wiederholt. | ||
+ | Die Variable workCounter wird auch hier verwendet, um sicherzustellen, | ||
+ | |||
+ | ===Block-Upload=== | ||
+ | Für das Hochladen von Blöcken gibt es einen Hintergrund-Thread, | ||
+ | ob timeChanged ungleich 0 ist und die Zeitdifferenz zwischen now und timeChanged größer als COW_MIN_UPLOAD_DELAY ist. | ||
+ | Ist dies der Fall, wird der Block hochgeladen. Die timeChanged Variable vor dem Upload wird zwischengespeichert. | ||
+ | Nach dem Hochladen wird timeChanged auf 0 gesetzt, wenn es noch die gleiche Zeit wie die zwischengespeicherte hat (wenn nicht, gab es eine Änderung während des Hochladens und es muss erneut hochgeladen werden). | ||
+ | Sobald das Image ausgehängt ist, wird COW_MIN_UPLOAD_DELAY ignoriert und alle Blöcke, die eine andere Zeit als 0 haben, werden hochgeladen. | ||
+ | Das Hochladen erfolgt über einen REST-Request. Es gibt zwei verschiedene Limits für die Anzahl der parallelen Uploads, diese können in der config.h konfiguriert werden. | ||
+ | |||
+ | ===Dateien=== | ||
+ | Wenn eine neue CoW-Sitzung gestartet wird, werden eine neue Meta-, Daten- und, falls in den Befehlszeilenargumenten festgelegt, eine status.txt-Datei erstellt. | ||
+ | |||
+ | ==status.txt== | ||
+ | Die Datei status.txt kann mit dem Kommandozeilenparameter --cowStatFile aktiviert werden. | ||
+ | |||
+ | Die Datei enthält die folgende Informationen: | ||
+ | < | ||
+ | uuid=< | ||
+ | state=backgroundUpload | ||
+ | inQueue=0 | ||
+ | modifiedBlocks=0 | ||
+ | idleBlocks=0 | ||
+ | totalBlocksUploaded=0 | ||
+ | activeUploads: | ||
+ | ulspeed=0.00 | ||
+ | </ | ||
+ | |||
+ | * Die **uuid** ist die Sitzungs-Uuid, | ||
+ | |||
+ | * Der **Status** ist **backgroundUpload**, | ||
+ | |||
+ | * **Queue** sind die CoW Blöcke, die gerade hochgeladen werden oder auf einen freien Slot warten. | ||
+ | |||
+ | * **ModifiedBlocks** sind CoW Blöcke, die Änderungen aufweisen, die noch nicht auf den Server hochgeladen wurden, weil die Änderungen zu aktuell sind. | ||
+ | |||
+ | * **totalBlocksUploaded** die Gesamtanzahl der CoW Blöcke, die seit dem Einhängen des Images hochgeladen wurden. | ||
+ | |||
+ | * **activeUploads** ist die Anzahl der Blöcke, die gerade hochgeladen werden. | ||
+ | |||
+ | * **ulspeed** die aktuelle Upload-Geschwindigkeit in kb/s. | ||
+ | |||
+ | Sobald alle Blöcke hochgeladen wurden, wird der Status auf erledigt gesetzt. Wenn Sie COW_DUMP_BLOCK_UPLOADS festlegen (in config.h), wird eine Liste aller Blöcke, sortiert nach der Anzahl der Uploads, in die Datei status.txt kopiert, nachdem der Block-Upload abgeschlossen ist. | ||
+ | |||
+ | Mit dem Kommandozeilenparameter --cowStatStdout wird die gleiche Ausgabe der Statistikdatei in stdout ausgegeben. | ||
+ | |||
+ | ==meta== | ||
+ | Die Metadatei enthält die folgenden Header: | ||
+ | < | ||
+ | // cowfile.h | ||
+ | typedef struct cowfile_metadata_header | ||
+ | { | ||
+ | uint64_t magicValue; | ||
+ | atomic_uint_least64_t imageSize; | ||
+ | int32_t version; | ||
+ | int32_t blocksize; | ||
+ | uint64_t originalImageSize; | ||
+ | uint64_t metaDataStart; | ||
+ | int32_t bitfieldSize; | ||
+ | int32_t nextL2; | ||
+ | atomic_uint_least64_t metadataFileSize; | ||
+ | atomic_uint_least64_t dataFileSize; | ||
+ | uint64_t maxImageSize; | ||
+ | uint64_t creationTime; | ||
+ | char uuid[40]; | ||
+ | char imageName[200]; | ||
+ | } cowfile_metadata_header_t; | ||
+ | </ | ||
+ | Nach diesem Header beginnt bei Byte 8192 die oben erwähnte l1- und dann die l2-Datenstruktur. | ||
+ | ==data== | ||
+ | Die Datendatei enthält den magicValue und am Offset 40 * 8 * 4096 (Kapazität eines cowfile_metadata_header_t) beginnt der erste Datenblock. | ||
+ | |||
+ | ==magic values in den Headern der Dateien== | ||
+ | Die magic values in beiden Dateien werden verwendet, um sicherzustellen, | ||
+ | < | ||
+ | //config.h | ||
+ | #define COW_FILE_META_MAGIC_VALUE ((uint64_t)0xEBE44D6E72F7825E) // Magic Value to recognize a Cow meta file | ||
+ | #define COW_FILE_DATA_MAGIC_VALUE ((uint64_t)0xEBE44D6E72F7825F) // Magic Value to recognize a Cow data file | ||
+ | </ | ||
+ | |||
+ | ===Threads=== | ||
+ | Diese Erweiterung verwendet zwei neue Threads: | ||
+ | < | ||
+ | tidCowUploader | ||
+ | tidStatUpdater | ||
+ | </ | ||
+ | * **tidCowUploader** ist der Thread, der die Blöcke auf den Cow-Server hochlädt. | ||
+ | |||
+ | * **tidStatUpdater** aktualisiert die Statistiken in stdout oder die Statistikdateien (je nach Parametern). | ||
+ | |||
+ | ===Locks=== | ||
+ | Diese Erweiterung verwendet einen neuen Lock cow.l2CreateLock. Er wird verwendet, wenn ein neues L2-Array zugewiesen wird. | ||
<note warning> | <note warning> |