lessfs を試す

Linux Jornalのコラムに惹かれてlessfsを試してみたくなった。
ちなみに、lessfsは「Deduplication」(ファイル重複除外?)を目的としたfuse。
他にも暗号化機能、レプリケーション機能(MasterSlave)や圧縮ストレージ機能もあって、
圧縮フォーマットにはLZO、QuickLZ、BZipその他色々あるらしい。

Deduplication自体は、一部で熱いらしいBtrfsやZFSにも搭載されている。
２つとも色々と問題があって、あまり簡単には導入出来ない。
そこでlessfsの登場。
fuseなだけに他のfuse系同様のボトルネックはあるものの、
アーカイブ用途ならパフォーマンス問題は少ないと思われる。

おまけでLinux Jornalでは、Opendedup も触れられていた。
こっちは、Javaかつシステムリソースの要求スペックが高いので論外。

lessfsで必要になるのが、

 tokyocabinet
 mhash
 fuse

の２つ。
メタ情報とかの管理にtokyocabinetを使っているらしいけど、
同様のDBMSとしてHamsterDBやBDBと色々いけるみたい。詳細不明。

早速、まずはCentOSで構築を始める...が5.6な環境のepelと標準リポジトリのパッケージでは、

tokyocabinetとfuseのバージョン古すぎて対応出来ない。

一番致命的なのはfuse。

色々と依存性が高いモジュールなだけに、CentOSは諦めた。

門前払いされた感じ。

お家騒動もあるし、CentOSにはウンザリしてきた。
野良ビルドするくらいなら、Debianに切り替える。

Debian（squeeze)で構築を始める。

ベアメタルな環境のため、

 apt-get install gcc zlib1g-dev libbz2-dev libmhash-dev pkg-config

で地盤作りから始める。

最初は、tokyocabinet（執筆時の最新版1.4.47）を構築する。

wget http://fallabs.com/tokyocabinet/tokyocabinet-1.4.47.tar.gz
tar xf tokyocabinet-1.4.47.tar.gz && cd tokyocabinet-1.4.47 
./configure && make && make install

次に、lessfs（執筆時の最新版1.4.7）

まずは、sourceforgeから取得。

tar xf lessfs-1.4.7.tar.gz && cd lessfs-1.4.7
./configure && make && make install

無事導入が終われば、まずは一段落。
同梱のlessfs.cfgを利用して一気に設定ファイル配置から初期化まで進める

cp etc/lessfs.cfg /etc/
mkdir -p /data/{dta,mta}
mklessfs -c /etc/lessfs.cfg

これでようやく準備が整ったので、

lessfs /etc/lessfs.cfg /mnt

でマウントしてみる。

ちなみに構築した環境下では、

root@dev:~# df
Filesystem           1K-blocks   Used      Available Use%  Mounted on
/dev/simfs            2097152    635080   1462072  31%   /
tmpfs                   393216         0          393216      0%   /lib/init/rw
tmpfs                   393216         0          393216     0%    /dev/shm
fuse                     2097152    635080   1462072  31%   /mnt

となっている。

実際に期待する働きをしてくれるのか実験する。
検証シナリオ：

1. 100MBの0埋めデータtest.datを作る      ( 通常は、100MB 消費する )
2. test.datをtest2.datにコピー                 ( 通常は、更に100MB 消費する ) 
3. テストデータ削除
4. 最新カーネルlinux-3.0-rc1.tar.bz2取得 ( 通常は、73MB 消費する )
5. linux-3.0-rc1.tar.bz2をlinux-3.0-rc1_2.tar.bz2 にコピー  ( 通常は、更に73MB 消費する )

実験結果:

root@dev:~# dd if=/dev/zero of=/mnt/test.dat bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1.05934 s, 99.0 MB/s


root@dev:~# df
Filesystem           1K-blocks   Used      Available Use%  Mounted on
/dev/simfs            2097152    635108   1462044  31%  /
tmpfs                   393216                0   393216      0%  /lib/init/rw
tmpfs                   393216                0   393216      0%  /dev/shm
fuse                     2097152    635108   1462044  31%  /mnt



root@dev:~# cp /mnt/test.dat /mnt/test2.dat
root@wp:~# df   

Filesystem           1K-blocks   Used       Available Use%  Mounted on
/dev/simfs            2097152    635108   1462044  31%   /
tmpfs                   393216                0   393216      0%   /lib/init/rw
tmpfs                   393216                0   393216      0%   /dev/shm
fuse                     2097152    635108   1462044  31%   /mnt


....色々と実施したので消費量が変動orz

root@dev:~# df
Filesystem           1K-blocks   Used       Available Use% Mounted on
/dev/simfs            2097152    635168   1461984  31%   /
tmpfs                   393216                0   393216      0%   /lib/init/rw
tmpfs                   393216                0   393216      0%   /dev/shm
fuse                     2097152    635168   1461984  31%   /mnt


root@dev:~# wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.0-rc1.tar.bz2 -O linux-3.0-rc1.tar.bz2
root@dev:~# df
Filesystem           1K-blocks   Used       Available Use% Mounted on
/dev/simfs            2097152    711200   1385952  34%   /
tmpfs                   393216                0   393216      0%   /lib/init/rw
tmpfs                   393216                0   393216      0%   /dev/shm
fuse                     2097152    711200   1385952  34%   /mnt

root@dev:~# cp /mnt/linux-3.0-rc1.tar.bz2 /mnt/linux-3.0-rc1_2.tar.bz2 
root@dev:~# df
Filesystem           1K-blocks   Used       Available Use% Mounted on
/dev/simfs            2097152    711200   1385952  34%   /
tmpfs                   393216                0   393216      0%   /lib/init/rw
tmpfs                   393216                0   393216      0%   /dev/shm
fuse                     2097152    711200   1385952  34%   /mnt

おぉ！ 圧縮されてるし、重複除去も効いている！！ 100MBが100KB未満!!!
あまりに消費量の変動のなさにオペミスかと思って何度も検証シナリオを実施してしまった。

一応、リアルなデータとしてカーネルで変動を見たものの、
圧縮済みアーカイブデータは再び圧縮されることで余分に消費しているように伺える。
格納データが、プログラムソースとかExcelやwordなら圧縮が有効に働きそう。
但し、コピーに対するオペレーションが若干遅い印象を受けた。
この動作は、実際の運用でありそうなsamba経由でのファイル操作でも同様なことを確認済み。
NFSは未検証。
FAQに、nfsにはunfs3を使うように記載がある。
FAQには、他にもVMware環境下のワークアラウンドが載っている。
一応、導入前にREADMEと併せてFAQは参照しておいた方がいい。

それにしてもdfを何度か繰り替えしていると、
 消費量増加 ー＞ 圧縮実施? ー＞ 消費量減少 ー＞ 消費量増加(圧縮前増加分)
と遷移が確認出来た。
ディスクフルギリギリまで詰め込んで運用していると、不味いシナリオが発生しそう...

ちなみに、分かる人には分かるけど、実行環境はOpenVZ。
そんな訳で、Bonnieなどによるレポートは現実的な値が出ない可能性が高いので止める。

[感想]
人柱erは、是非ともお試しを。
但し、真面目に運用するには、バックアップは別途実施すべき。
他のファイルシステムでRAID0組んでれば安全！といった妄想が成立しないのと一緒。