ext4 → btrfs に変更
gitlabストレージに使ってるHDDが、よく考えたら大量のwordpressだらけで、はっきり言って容量の無駄使いなので、btrfs に変えて重複ファイルの排除機能を使えば節約になりそうな気がした。
手順１
fsck でエラーを修正しておく
fsck /dev/mapper/storage-root
手順２変換する
使うコマンドはbtrfs-convert である。進捗をだすために -p を見ている
btrfs-convert -p /dev/mapper/vgubuntu-root
create btrfs filesystem:
blocksize: 4096
nodesize: 16384
features: extref, skinny-metadata (default)
checksum: crc32c
creating ext2 image file
creating btrfs metadata
copy inodes [O] [ 698961/ 313176]
conversion complete
ただし、一時ファイルが必要みたい 進捗を見る限り直接ファイルシステムを変更するわけではなく、一時ファイルを経由するみたいだから、多少の空き容量が必要であると予想される。
creating ext2 image file
変換結果の確認
変換された結果を閲覧する。btrfs はマウントしてデータを見る。
sudo mount /dev/mapper/vgubuntu-root ./disk sudo btrfs filesystem show ./disk
実際の動作例。
sudo btrfs filesystem show disk
[sudo] password for takuya:
Label: none uuid: 7f7eb691-81a0-4184-89cb-a8d3b67c8672
Total devices 1 FS bytes used 90.58GiB
devid 1 size 498.54GiB used 117.37GiB path /dev/mapper/vgubuntu-root
btrfs の機能である重複排除や透過圧縮が聞いてるとディスクサイズがガラッと変わってくる。
df を見る
btrfs は df がつかえなくなる(あてにならない）ので、btrfs df コマンドを代わりに使う。
sudo btrfs filesystem df ./disk
実際の例。
sudo btrfs filesystem df ./disk Data, single: total=115.22GiB, used=90.81GiB System, single: total=4.00MiB, used=112.00KiB Metadata, single: total=1.45GiB, used=450.69MiB GlobalReserve, single: total=110.61MiB, used=0.00B
df よりusage のほうが見やすいので私はこっちが好き
sudo btrfs filesystem usage ./disk
Overall:
Device size: 498.54GiB
Device allocated: 115.60GiB
Device unallocated: 382.94GiB
Device missing: 0.00B
Used: 90.65GiB
Free (estimated): 406.87GiB (min: 406.87GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 110.33MiB (used: 16.00KiB)
Data,single: Size:114.14GiB, Used:90.21GiB (79.03%)
/dev/mapper/vgubuntu-root 114.14GiB
Metadata,single: Size:1.45GiB, Used:450.42MiB (30.27%)
/dev/mapper/vgubuntu-root 1.45GiB
System,single: Size:4.00MiB, Used:112.00KiB (2.73%)
/dev/mapper/vgubuntu-root 4.00MiB
Unallocated:
/dev/mapper/vgubuntu-root 382.94GiB
マウントを変更する ext4 → btrfs
btrfs に変更されると、ディスクのUUIDが変わるので、マウントを変えてあげないとだめなことがある。
私の場合は、/dev/mapperで指定してたので、UUIDは使ってないので特にUUID変更の必要はなかった。
ただし、ファイルシステムについては、fstabにext4 を記載部分を btrfs に変更する必要があった。
before
# /etc/fstab: static file system information. # <file system> <mount point> <type> <options> <dump> <pass> # /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 /dev/mapper/vgubuntu-root / btrfs errors=remount-ro 0 1
UUIDでマウントをしている場合は、uuidも手動で変更してあげる。
mount /dev/mapper/xxx-root disk blkid vim disk/etc/fstab
マウントオプション
btrfs にはいくつかオプションがあるので、マウントオプションを検討する。（後述）
通常は変換後は、ただ何も考えずに使えばいい。
サイズを調整する。
任意。btrfs でディスクサイズがいい感じに節約されたときは、リサイズを掛けたくなるとおもう。
縮小
btrfs filesystem resize -100GB ./disk
拡大
btrfs filesystem resize +10GB ./disk
指定サイズへ
btrfs filesystem resize 300GB ./disk
パーティション最大へ
btrfs filesystem resize max ./disk
マウントオプションによるチューニング
CoW の有効無効に注意する
CoWを有効化するかどうか。Raspberry Pi のようなSDカードメインだとCoWは著しく寿命を縮める可能性があるが、ログファイルなどは、journalctl で volalite（揮発性）にしてしまえばCoWがenabledでも問題なさそうだ。DBストレージの場合は、DBが入ってるディレクトリだけchattr してあげたほうが良さそう。
圧縮を透過圧縮にするかどうか、これも検討した方がいい。テキストファイルを扱うことが多いなら透過圧縮はストレージ容量を大幅に節約することができると思う。とくにgitlab のようなテキストファイルを大量に扱うストレージなら、btrfs で重複排除されるうえに、文字列が多いので圧縮が非常に効くと思う。ただし物理的破損がおきたらデータ喪失量も膨大になりそうだ。ちょっと諸刃の剣。CPU負荷も少し上がりそうだよね。書き込み総量が少なくなるので、SSDの寿命に優しくなるので、電気代・書き込み量・扱うデータを考えて、こちらも少し思案したほうが良さそう。設計に困ったら、特定のディレクトリだけを圧縮するchattr が使えるのでbtrfs は強い。
ext4→btrfs変換後に再圧縮（初期圧縮）をかける
btrfs filesystem defragment -r -v -c XXX /
trim で SSD TRIM
マウントオプション discard=asyncで、自動的にtrim が実行される。コミット待ちが発生するので、メモリ量と書き込み頻度と相談。
その他のマウントオプション
- ssd： SSD最適化された動作の一部をオンにします
- ssd_spread： 大きな空き領域を一括で割り当てることでパフォーマンスの向上を図るらしい。
- inode_cache： 空きinode番号のキャッシュを有効にします。
メンテナンス
最低限のメンテナンス手順だけ覚えておく
btrfs filesystem defragment -r ./disk btrfs scrub ./disk # btrfs check ./disk # 普通はやらない
