ただ、UEKr2 なら、別の選択肢として Btrfs も利用できるので、一部のデータの格納に使ってみることにしました。
期待しているのは、透過圧縮機能 (compress-force=lzo) と raid1 です。
# mkfs.btrfs -m raid1 -d raid1 /dev/sd[bc]2 # mount -t btrfs -o compress-force=lzo /dev/sdb2 /mnt_hogeネット上に沢山の例がありますが、こんな感じで、mkfs と mount を行います。
Btrfs の raid1 は、構成デバイスのうちの１つだけ (上記の例なら sdb2 または sdc2) を指定すれば mount できるという特徴があります。おもしろいアイデアだと思いますが、md に慣れているわたしには、操作対象が定まらずしっくりこない感じがしました。まあ、慣れの問題かとは思いますが。
ここまでは、いたって簡単です。しかし、起動時に自動マウントしようとしたら、うまく行きませんでした。
UUID=ae4ac311-4ef1-478a-a4eb-15bfa4beedc4 /mnt_hoge btrfs defaults,compress-force=lzo 1 1ext4 等と同じ感覚で fstab に上記のように記載したのですが、起動時に自動マウントされず、次のようなメッセージが出ていました。
device fsid ae4ac311-4ef1-478a-a4eb-15bfa4beedc4 devid 1 transid 431 /dev/sdb2 btrfs: force lzo compression btrfs: disk space caching is enabled btrfs: failed to read the system array on sdb2 btrfs: open_ctree failedしばらく格闘した結果、システム起動時のマウント処理の時点では、sdc2 が Btrfs の構成デバイスと認識されていないためと分かりました。
# btrfs device scan Scanning for Btrfs filesystems上記コマンドによるスキャン実施後であれば、mount -a でマウントできたため、そのように判断しました。
fstab に指定されたローカルファイルシステムのマウントは、rc.sysinit で行われるので、rc.sysinit を書き換えて、事前に btrfs device scan を実行するようにしてしまえば良さそうですが、今後の initscripts パッケージのアップデートを考えると、毎度・毎度、書き換えるのも手間だし、忘れそうだし・・・ということで、独自のサービス (my_btrfs) を作成して対処することにしました。
#!/bin/bash
#
# my_btrfs This shell script takes care of starting btrfs
# on CentOS 5 + UEKr2
#
# chkconfig: 2345 02 99
# description: initializing btrfs for my server
#
# config:
### BEGIN INIT INFO
# Provides: my_btrfs
# Required-Start:
# Required-Stop:
# Default-Stop: 0 1 2 3 6
# Short-Description: initializing btrfs
# Description: initializing btrfs
#
### END INIT INFO
#
# Authors: luna2 <blue3waters at gmail dot com>
#
# This file is subject to the GNU General Public License.
# It comes with NO WARRANTY.
#
LOCKFILE=/var/lock/subsys/my_btrfs
case "$1" in
start)
modprobe btrfs
if [ $? -eq 0 ] ; then
btrfs device scan
mount -a -t btrfs
touch $LOCKFILE
fi
;;
stop)
rm -f $LOCKFILE
;;
*)
echo "Usage $0 start | stop "
;;
esac
このスクリプトを /etc/init.d/ に配置して、
# ls -l /etc/init.d/my_btrfs -rwxr-xr-x 1 root root 816 Feb 2 13:36 /etc/init.d/my_btrfs # chkconfig --add my_btrfs # chkconfig my_btrfs on # chkconfig --list my_btrfs my_btrfs 0:off 1:off 2:on 3:on 4:on 5:on 6:offという具合にサービス登録します。くわえて、fstab を次のように修正しました。
UUID=ae4ac311-4ef1-478a-a4eb-15bfa4beedc4 /mnt_hoge btrfs defaults,_netdev,compress-force=lzo 1 1この _netdev を指定すると、rc.sysinit による mount がスキップされます。オンラインマニュアル mount(8) 参照。
これで、システム起動時に Btrfs raid1 領域が自動マウントされるようになりました。次のメッセージは、正常に自動マウントされた際のものです。
Btrfs loaded device fsid ae4ac311-4ef1-478a-a4eb-15bfa4beedc4 devid 1 transid 452 /dev/sdb2 device fsid ae4ac311-4ef1-478a-a4eb-15bfa4beedc4 devid 2 transid 452 /dev/sdc2 device fsid ae4ac311-4ef1-478a-a4eb-15bfa4beedc4 devid 1 transid 452 /dev/sdb2 btrfs: force lzo compression btrfs: disk space caching is enabled
なお、initscripts は Oracle Enterprise Linux 5 向けのものに置き換えています・・・
# rpm -qi initscripts Name : initscripts Relocations: (not relocatable) Version : 8.45.44 Vendor: Oracle America Release : 3.0.1.el5 Build Date: Wed 02 Oct 2013 09:51:05 AM JST Install Date: Sun 20 Oct 2013 07:35:23 AM JST Build Host: ca-build56.us.oracle.com Group : System Environment/Base Source RPM: initscripts-8.45.44-3.0.1.el5.src.rpm Size : 5508014 License: GPLv2 and GPLv2+ Signature : DSA/SHA1, Wed 02 Oct 2013 09:51:16 AM JST, Key ID 66ced3de1e5e0159 URL : http://git.fedorahosted.org/git/initscripts.git Summary : The inittab file and the /etc/init.d scripts. Description : The initscripts package contains the basic system scripts used to boot your CentOS system, change runlevels, and shut the system down cleanly. Initscripts also contains the scripts that activate and deactivate most network interfaces. # grep -i btrfs /etc/rc.d/rc.sysinit ※とりたてて、btrfs への配慮はない？のかな・・・ #
2014-02-12追記
compress-force=lzo の効果について、ちょっと確認してみました。CentOS 6 のシステムイメージを tar で固めたファイルを、展開・削除した場合の比較です（圧縮なし、compress=lzo、compress-force=lzo の３パターン）。
[root@hoge ~]# uname -a
Linux hoge 2.6.39-400.214.1.el5uek #1 SMP Tue Feb 4 17:15:09 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# cat /etc/redhat-release
CentOS release 5.9 (Final)
[root@hoge ~]# mount /dev/sdb2 /mnt_sdb2
[root@hoge ~]# cd /mnt_sdb2
[root@hoge mnt_sdb2]# ls -l
total 10671332
-rw-r--r-- 1 root root 10927441920 Oct 20 22:44 sda6.tar
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 7.8G 180G 5% /mnt_sdb2
[root@hoge mnt_sdb2]# grep btrfs /proc/mounts
/dev/sdb2 /mnt_sdb2 btrfs rw,relatime,space_cache 0 0
[root@hoge mnt_sdb2]# time tar xf sda6.tar
real 4m1.898s
user 0m2.548s
sys 0m27.315s
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 29G 160G 15% /mnt_sdb2
[root@hoge mnt_sdb2]# sysctl -w vm.drop_caches=3
vm.drop_caches = 3
[root@hoge mnt_sdb2]# time rm -rf test.restore/
real 0m44.677s
user 0m0.272s
sys 0m16.817s
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 8.0G 180G 5% /mnt_sdb2
[root@hoge mnt_sdb2]# cd
[root@hoge ~]# umount /mnt_sdb2
[root@hoge ~]# mount -o compress=lzo /dev/sdb2 /mnt_sdb2
[root@hoge ~]# cd /mnt_sdb2
[root@hoge mnt_sdb2]# ls -l
total 10671332
-rw-r--r-- 1 root root 10927441920 Oct 20 22:44 sda6.tar
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 7.8G 180G 5% /mnt_sdb2
[root@hoge mnt_sdb2]# grep btrfs /proc/mounts
/dev/sdb2 /mnt_sdb2 btrfs rw,relatime,compress=lzo,space_cache 0 0
[root@hoge mnt_sdb2]# time tar xf sda6.tar
real 3m52.773s
user 0m2.652s
sys 0m27.360s
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 24G 164G 13% /mnt_sdb2
[root@hoge mnt_sdb2]# sysctl -w vm.drop_caches=3
vm.drop_caches = 3
[root@hoge mnt_sdb2]# time rm -rf test.restore/
real 0m30.179s
user 0m0.250s
sys 0m15.596s
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 7.8G 180G 5% /mnt_sdb2
[root@hoge mnt_sdb2]# cd
[root@hoge ~]# umount /mnt_sdb2
[root@hoge ~]# mount -o compress-force=lzo /dev/sdb2 /mnt_sdb2
[root@hoge ~]# cd /mnt_sdb2/
[root@hoge mnt_sdb2]# ls -l
total 10671332
-rw-r--r-- 1 root root 10927441920 Oct 20 22:44 sda6.tar
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 7.8G 180G 5% /mnt_sdb2
[root@hoge mnt_sdb2]# grep btrfs /proc/mounts
/dev/sdb2 /mnt_sdb2 btrfs rw,relatime,compress-force=lzo,space_cache 0 0
[root@hoge mnt_sdb2]# time tar xf sda6.tar
real 2m21.203s
user 0m2.665s
sys 0m27.380s
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 16G 173G 9% /mnt_sdb2
[root@hoge mnt_sdb2]# sysctl -w vm.drop_caches=3
vm.drop_caches = 3
[root@hoge mnt_sdb2]# time rm -rf test.restore/
real 0m30.308s
user 0m0.285s
sys 0m15.576s
[root@hoge mnt_sdb2]# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 196G 7.8G 180G 5% /mnt_sdb2
[root@hoge mnt_sdb2]# cd
[root@hoge ~]# btrfs fi df /mnt_sdb2
Data, RAID1: total=15.00GB, used=3.87GB
System, RAID1: total=64.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=4.00GB, used=18.90MB
[root@hoge ~]# btrfs fi show
Label: none uuid: ae4ac311-4ef1-478a-a4eb-15bfa4beedc4
Total devices 2 FS bytes used 3.89GB
devid 2 size 97.66GB used 19.06GB path /dev/sdb2
devid 1 size 97.66GB used 19.07GB path /dev/sdc2
圧縮処理によりディスクアクセスが減って、処理時間が短縮されることを確認しました。そしてなにより、もちろんディスクが節約され、なかなかナイスです。ただ、安定して利用できるのか未知数であり、重要なデータは格納しないほうがいいのではないかと思います。2014-02-19追記
片方のディスクを抜いて起動した場合にマウントできるか試してみたら、ダメでした。。。
うーむ、そのレベルだと使うのは不安ですね。圧縮機能にだけ期待して、md RAID1 の上に Btrfs を重ねるかな。。。不良セクタ発生時のセルフヒーリングにも期待したかったのですが。
あるいは、冒険はやめて、やっぱり ZFS 一辺倒にするか。
それにしても、オラクルは Btrfs をサポートすると言ってますが、エンタープライズ向けディストリビューションとしては、少々無理があるように思いました。
2014-03-25追記
同じ tar ファイル（sda6.tar 約10GB）を使って ZFS の性能を測ってみました。下記参照。
３つのOSでZFSの性能を比較
2014-05-20追記
https://wiki.archlinux.org/index.php/Btrfs#Creating_a_new_file_system
によると、ごく最近（2013年12月）、デフォルトのブロックサイズが 16k に変更されており、ほとんど全てのワークロードについて faster であるとのこと、それは耳寄りな話しだと思い、さっそく試してみました。
まず、もう一度 mkfs.btrfs です。
# mkfs.btrfs -n 16k -l 16k -m raid1 -d raid1 /dev/sd[bc]2
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
adding device /dev/sdc2 id 2
fs created label (null) on /dev/sdb2
nodesize 16384 leafsize 16384 sectorsize 4096 size 195.31GB
Btrfs Btrfs v0.19
で、前に実験に使った tar ファイルを用いて、展開・削除性能を計ってみました。ただし、compress-force=lzo の場合のみです。
[root@hoge ~]# uname -r 2.6.39-400.214.5.el5uek [root@hoge ~]# cd /mnt_sdb2/ [root@hoge mnt_sdb2]# grep btrfs /proc/mounts /dev/sdd2 /mnt_sdb2 btrfs rw,relatime,compress-force=lzo,space_cache 0 0 [root@hoge mnt_sdb2]# df -h . Filesystem Size Used Avail Use% Mounted on /dev/sdd2 196G 7.6G 186G 4% /mnt_sdb2 [root@hoge mnt_sdb2]# ls -l sda6.tar -rw-r--r-- 1 root root 10927441920 Oct 20 2013 sda6.tar [root@hoge mnt_sdb2]# time tar xf sda6.tar real 1m43.496s user 0m2.245s sys 0m23.133s [root@hoge mnt_sdb2]# df -h . Filesystem Size Used Avail Use% Mounted on /dev/sdd2 196G 16G 179G 8% /mnt_sdb2 [root@hoge mnt_sdb2]# sysctl -w vm.drop_caches=3 vm.drop_caches = 3 [root@hoge mnt_sdb2]# time rm -rf test.restore real 0m15.924s user 0m0.185s sys 0m9.921sわたしの環境では効果が見られ、rm の処理時間が約半分になりました。これは、ありがたい。
2014-05-22追記
RHEL7.0 RC を調べていますが、デフォルトのブロックサイズ（node size と leaf size）は 4k のままでした。
2014-06-26追記
node size と leaf size を確認する方法を書いてなかったので、追記。
# uname -a Linux hoge 3.10.0-121.el7.x86_64 #1 SMP Tue Apr 8 10:48:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux # btrfs-show-super /dev/sdb2 superblock: bytenr=65536, device=/dev/sdb2 --------------------------------------------------------- csum 0x1f36f324 [match] bytenr 65536 flags 0x1 magic _BHRfS_M [match] fsid 32387714-ab8f-4b84-8648-e99ff10a4082 label btrfs201405 generation 179 root 83771392 sys_array_size 226 chunk_root_generation 84 root_level 0 chunk_root 21004288 chunk_root_level 0 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 209717346304 bytes_used 4044537856 sectorsize 4096 nodesize 16384 leafsize 16384 stripesize 4096 root_dir 6 num_devices 2 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x29 csum_type 0 csum_size 4 cache_generation 179 uuid_tree_generation 179 dev_item.uuid d39e3ff2-c899-462d-b60f-94366e424cd0 dev_item.fsid 32387714-ab8f-4b84-8648-e99ff10a4082 [match] dev_item.type 0 dev_item.total_bytes 104858673152 dev_item.bytes_used 16135487488 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size 4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0OracleLinux 5 提供の btrfs-progs には、このコマンドは収録されていません。CentOS6/RHEL6 も未収録（RHEL6.5 は Technology Preview ですけど）。
なお、レッドハットは、RHEL7.0 においては、Btrfs は Technology Preview のようです。最終的に公開された英語版リリースノートに書いてました。レッドハットは良識がありますね。と、思いました。
ですけど Btrfs は、もう一息かなという感触を持ってます。ユーザデータ格納ならば、わたしなら ZFS を選択しますが、ルートVOL（/）として使うには、Btrfs のほうがいいように思ってます。ZFS も、がんばればルートVOLとして使えますが、ZFS 自体のバージョンアップ時や、カーネルバージョンアップの際に気をつけて作業する必要があります。あと、ZFS 0.6.3 では、まだ SELinux と併用すると性能が出ないようです。
2014-07-21追記
手持ちマシンのうちの１台で、ルートVOL（/）を Btrfs RAID1（Plextor SSD M6M 128G x 2）にして CentOS7 を使い始めました。マルチブート環境ですが、Btrfs RAID1 に GRUB2 をインストールしても平気なようです。インストール時は、ext4 で１パーティションにインストールして、btrfs-convert で ext4 から Btrfs に変換して起動できる状態にし、さらに btrfs device add と btrfs balance start -dconvert=raid1 -mconvert=raid1 で、RAID1 化しました。ブロックサイズ 16k 化を忘れてました（mkfs し直さないと変更できません）、それと透過圧縮も利用していません。繰り返しますが、Btrfs は RHEL7.0 では Technology Preview になってますので、留意が必要です。わたしの個人的・実験的利用では、何も不都合はありませんが、大事なデータを置くのはやめたほうが良いだろうと思います。
2014-08-30追記
触れていなかったと思いますが、Btrfs RAID1 にした場合、df がレポートする Size が二倍に見えます。錯覚で広々とした感覚になりますが、これが曲者で、本日、大容量のファイル（バックアップ）を格納しようとして、空き容量の半分しか使えないことを忘れ、無駄な時間を費やしてしまいました。
[root@hoge ~]# uname -a Linux hoge 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@hoge ~]# btrfs fi show --mounted Label: btrfs201405 uuid: 32387714-ab8f-4b84-8648-e99ff10a4082 Total devices 2 FS bytes used 54.48GiB devid 1 size 97.66GiB used 56.03GiB path /dev/sdb2 devid 2 size 97.66GiB used 56.01GiB path /dev/sdc2 Btrfs v3.12 [root@hoge ~]# df -h /mnt_temp Filesystem Size Used Avail Use% Mounted on /dev/sdb2 196G 109G 85G 57% /mnt_tempこの Btrfs RAID1 領域は、sdb2 と sdc2 で構成されていて、それぞれ 約97G なのですが、df では Size が 196G に見え、空き(Avail)も 85G に見えています。しかしながら、実際に書き込めるのは、RAID1 を加味すると 85G の半分ということになります。本日は、そのことを忘れて、、、”おっ、まだ 85G も書き込めるのか”っと見誤り、50G を越えるサイズのデータを書き込もうとして、途中で失敗してしまいました。
Btrfs RAID1 を使い始めた当初、ちょっと変わっているが、錯覚で広々な感じで、なかなか good かもと思ってましたが、運用上は気をつけないと余計なトラブルの元になりますね。今になって、実にわかりにくい仕様だと再認識（実体験）したのでした。Btrfs 開発者の方、主義主張（あるいは実装上の都合？）があってのこととは思いますが、考え直してもらえないもんでしょうかね。
■関連記事
CentOS 7.2 で Btrfs RAID1 の df 出力が素直になっていた件
0 件のコメント:
コメントを投稿