Ich versuche, alle relevanten Auswirkungen des --max-obj-size-Wertes zu verstehen, der beim Erstellen einess3qlDateisystem. Ich habe noch keine vollständige Beschreibung der Auswirkungen dieser Option gefunden, konnte aber einige Informationen aus den Dokumenten und Diskussionsgruppen zusammentragen.
Hauptsächlich habe ich Gründe gefunden, größere --max-obj-size-Werte zu verwenden, was mich fragen lässt, warum nicht ein beliebig großer Wert verwendet wird (10 MB? 100 MB? 1 GB?):
- Kleinere Werte bedeuten, dass mehr „Inodes“ verwendet werden und die Leistung der SQLite-Datenbank schlechter ist (da für die gleiche Anzahl von Dateien mehr Inode-Einträge erforderlich sind).
- Kleinere Werte können den Durchsatz beeinträchtigen (insbesondere beisequentielles Lesen).
Ab der Version 1.8Änderungsprotokoll:
Tatsächlich bewirkt eine kleine S3QL-Blockgrößenichthat keinen Vorteil gegenüber einer großen Blockgröße, wenn viele kleine Dateien gespeichert werden. Eine kleine Blockgröße verschlechtert die Leistung jedoch erheblich, wenn größere Dateien gespeichert werden. Dies liegt daran, dass S3QL effektiv eine dynamische Blockgröße verwendet und der Wert --blocksize praktisch eine Obergrenze angibt.
Die einzigen Vorteile, die ich bisher bei kleineren Blockgrößen gefunden oder mir vorgestellt habe, sind:
- Weniger Bandbreite zum erneuten Schreiben eines Teils einer Datei
- Möglicherweise bessere Deduplizierung
Die Option --min-obj-size hat keinen Einfluss auf die Deduplizierung. Die Deduplizierung erfolgt, bevor Blöcke gruppiert werden.
Die Option --max-obj-size beeinflusst die Deduplizierung, da sie implizit die maximale Größe eines Blocks bestimmt.
GefundenHier:
Kann jemand eine Zusammenfassung der Kompromisse anbieten, die man eingeht, wenn man beim Erstellen eines S3QL-Dateisystems eine größere oder kleinere --max-obj-size auswählt?