Portageツリーのディレクトリ(PORTDIR)をSquashfsに圧縮(概要と下準備)
Portageのディレクトリツリーはファイル数が非常に多く、ハードディスクのアクセスに時間がかかる上に、ファイルシステムによっては領域も無駄に広く使ってしまう。*1
アクセス速度に関しては、ツリーごとtmpfs上に配置すれば良さそうに思えたのだが、メモリ使用量がものすごいことになってしまう。しかし、Squashfsで圧縮すると、全てのディレクトリを含めても50MiB弱程度のサイズしか使用しない。
圧縮率はミラーサーバにある.tar.bz2圧縮されたスナップショット(約40MiB)に劣るものの
(mksquashfsの出力例)
Filesystem size 47887.02 Kbytes (46.76 Mbytes)
25.62% of uncompressed filesystem size (186891.69 Kbytes)
Inode table size 1724820 bytes (1684.39 Kbytes)
35.41% of uncompressed inode table size (4870494 bytes)
Directory table size 1526091 bytes (1490.32 Kbytes)
41.30% of uncompressed directory table size (3694858 bytes)かなり良く、使用しない分野のディレクトリを消してしまえばもっと小さくでき、圧縮(Squashfsの作成)時間も短縮できる。
利点
Portageツリーの中にあるebuildファイルの読み込みは非常に高速になり、特にテキスト検索(portage-utilsのqgrepなど)をするときに効果が実感できる他、ハードディスクに優しくなるのも大きい。tmpfs上にSquashfsファイルを置くと更に効果的。欠点
利点の割に設定の手間が多く、デメリットも多いため、この試みは実験的なものと言えそう。- rsyncを実行するときのために、書き込み可能なディレクトリツリー(未圧縮Portageツリー)を用意しておく必要が出る。Squashfsはこれと別にディスク領域を使用する
- パッケージインストール前の計算時には別のキャッシュを使用する*2ことや、インストール済みのパッケージのデータベース(/var/db/pkg/以下のファイル群)にアクセスすることなどもあり、この計算を高速化する効果は期待できない。キャッシュに関してはPortageのsqlite3化を行うと多少高速化される
- Portageツリーの更新(emerge --sync)ごとにSquashfsの作成(圧縮)も行う分だけCPUに負荷がかかる上、頻繁にツリー更新する場合は時間も余計にかかるようになる
- Portageツリーが読み取り専用になることにより、一部のディレクトリは場所を変更する必要の出る場合がある。更に、「一時的にPortageツリー内のebuildを少し修正してインストールする」といったことができず、ローカルOverlayにファイルを配置する必要が出る
