Optimierungen

Neben einer verteilten Datenablage für die Ausgangs- und Metadaten, sollte man darauf achten, eine möglichst große Blockdimension zu wählen. Empfohlen werden 64- oder 128-KByte-Blöcke, damit der Overhead nicht so groß wird (BLKSIZE=131072).

Die standardmäßig vorgegebene Hash-Länge von 24 Byte (=192 Bit), sowie die Hash-Methode "Tiger-192" brauchen kaum Anpassungen. Alternativ existiert noch "Midnight-Blue-Wish" als Hash-Algorithmus mit einer möglichen Hash-Länge von 20 bis 32Byte. Je kleiner die Hash-Länge, desto mehr Performance gibt es. Jedoch steigt gleichzeitig auch die Wahrscheinlichkeit einer Hash-Kollision.

Der Autor von lessfs empfiehlt jedoch die Blockdaten nicht in der TokyocabinetDB abzulegen, sondern als normale Datei.

Dafür passt man den Eintrag in der Konfiguration an (In "/dedup" liegen die Dateien vom Autor - bitte anpassen!) und kommentiert folgende Einträge aus:

# tokyocabinet

#BLOCKDATA_PATH=/dedup/dta

#BLOCKDATA_BS=1048576

Folgende Einträge sind ohne Kommentarzeichen zu versehen:

BLOCKDATA_IO_TYPE=file_io

BLOCKDATA_PATH=/dedup/dta/blockdata.dta

Dabei werden die bisherigen Dateien in "blockdata.tcb" nicht mehr genutzt und sie sind somit nicht mehr sichtbar. Hängt man jedoch ein neues Verzeichnis mit den Anpassungen ein und passt vorher die Konfiguration an, dann kann man die Dateien so verschieben.

Die CACHESIZE in Megabyte sollte man nicht all zu groß wählen, denn sonst ist das System mit I/O beschäftigt und nicht sehr reaktiv.

Im eingehängten Verzeichnis, das heißt die zweite Option von lessfs, gibt es ein Verzeichnis mit Namen ".lessfs". Dort findet sich eine Datei "lessfs_stats", die über den Deduplizierungs- und Komprimierungserfolg Auskunft gibt.