2014年12月21日日曜日

ThinkPad W520 の HDD を SSD へ引越し

4年間ほどメインマシンとして ThinkPad T510 (Core i7 M620) を使っており、まだまだ使えそうなのですが、ついついと中古で ThinkPad W520 (Core i7 2960XM) を入手してしまいました。いくつかのベンチマークで、T510 よりも 1.5 倍程度の性能でした。W520 は、メモリスロットが4スロットあり、最大で32Gまで対応できますが、そこまでは不要と判断して、16G(4Gx4枚)としました。そして、W520 は SATA 3.0 対応であり、わたしの自宅マシンとしては初モノです。
というわけで、仕上げに、HDD を SSD に引っ越しましたので、その手順をメモしておきたいと思います。

内蔵されていた HDD は、HITACHI HTS725050A9A364 の容量 500G 7200RPM でした。
どのベンダーの SSD に換装しようかと思ったのですが、今回は自分の中でイメージが良い SanDisk のものを使ってみることにしました。今も使っている Sony CLIE で、SanDisk 製の MemoryStick を長年使っており、高速だし実績もあるというイメージを持っています。
そんなわけで、Extreme PRO 240G をチョイスしました。

引越し作業は、USB HDD 上にインストールした CentOS 7 から起動して行いました。ちなみに W520 は、USB 3.0 対応でもあるのですが、残念ながら USB 3.0 では CentOS 7 を起動できず、USB 2.0 ポートから起動して作業しました。
プリインストールされていた Win7 のパーティションは、次のようになっていました。
# fdisk -u -l /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x153c11d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     3074047     1536000    7  HPFS/NTFS/exFAT
/dev/sda2         3074048   944003071   470464512    7  HPFS/NTFS/exFAT
/dev/sda3       944003072   976771071    16384000    7  HPFS/NTFS/exFAT
sda1 が Win7 のシステムパーティション、sda2 が Win7 の本体、sda3 がリカバリ領域 (所謂 D2D 領域) です。

まず最初に、sda2 を gparted で縮小しました。ここで、NTFS パーティションを操作するためには、ntfs-3g と ntfsprogs を入れておく必要があります。どちらも EPEL に収録されています。
縮小後のサイズは、次の通りです。
# fdisk -u -l /dev/sda
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     3074047     1536000    7  HPFS/NTFS/exFAT
/dev/sda2         3074048   134146047    65536000    7  HPFS/NTFS/exFAT
/dev/sda3       944003072   976771071    16384000    7  HPFS/NTFS/exFAT
次に、ディスクの先頭から sda2 の末尾 (sector 134146047) までを、dd コマンドで SSD にコピーしました。SSD は、2nd HDD アダプターに接続。
# echo "134146047 * 512 / 65536" | bc
1048015
# dd if=/dev/sda of=/dev/sdb bs=65536 count=1050000 conv=sparse
必ずそうであるとは断言できませんが、新品の SSD は、全領域がゼロデータのはずなので、conv=sparse でゼロデータをスキップしてコピーしました。ここで、パーティションテーブルも一緒にコピーされたので、不正になった sdb3 を fdisk で削除して、正確に同じサイズの sdb3 を作成しました。
# fdisk -u -l /dev/sdb

Disk /dev/sdb: 240.1 GB, 240057409536 bytes, 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x153c11d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048     3074047     1536000    7  HPFS/NTFS/exFAT
/dev/sdb2         3074048   134146047    65536000    7  HPFS/NTFS/exFAT
/dev/sdb3       134146048   166914047    16384000    7  HPFS/NTFS/exFAT
不要かもしれないとは思いつつ、パーティション 3 の D2D 領域もコピーしました。
# blkdiscard /dev/sdb3  ※1回目の dd で少し余分にコピーしたので、TRIM でクリア
# dd if=/dev/sda3 of=/dev/sdb3 bs=65536 conv=sparse
うまくコピーできたかどうか、md5sum 値を確認。
# dd if=/dev/sda1 bs=65536 | md5sum
# dd if=/dev/sdb1 bs=65536 | md5sum

# dd if=/dev/sda2 bs=65536 | md5sum
# dd if=/dev/sdb2 bs=65536 | md5sum

# dd if=/dev/sda3 bs=65536 | md5sum
# dd if=/dev/sdb3 bs=65536 | md5sum
これで、完全にコピーが終わったので、HDD を取り出して SSD に換装して起動、、、うまくいきました!
D2D リカバリーが出来るかどうかまでは確認していませんが、マシン起動時に ThinkVantage ボタンで D2D リカバリーのメニューには辿り着けました。

余談になりますが、CentOS 7 向けの ntfs-3g は、fstrim に対応しているようです。
# rpm -q --changelog ntfs-3g | less
...
* Thu Jul 31 2014 Richard W.M. Jones <rjones@redhat.com> - 2:2014.2.15-4
- Upstream patches which add fstrim support.
いちおう、最後のしめに、コピーした Win7 のパーティションに fstrim をかけました。
本当に fstrim が機能しているか、念のため小さいパーティションで試しましたが、ちゃんと動いているようでした。削除したファイル(ある程度大きいサイズのファイル)の痕跡が消えることを確認しました。

2015-09-08追記
その後、SSD の後半に CentOS を入れて、MBM でマルチブート運用しているのですが、その状態だと ThinkVantage ボタンで D2D リカバリーのメニューを呼び出すことが出来なくなるようです。しかし、MBM で Win7 のシステムパーティションを選択後に F2 連打、そのあと F8 押下で、「システムの回復」を選択すれば D2D リカバリに辿り着けました。ただし、本当にリカバリできて、しかも後半の CentOS パーティションに影響ないのか不明。試行してません。

ZFS の upgrade について

ZFS on Linux を利用し始めた初期 (2012年前半) に作成した zpool のバージョンが、古いままだった(version 23)ので、lz4 圧縮を使うために zpool upgrade を行いました。そうしたところ、なぜか tar ファイル展開で、展開したファイルのパーミッションがおかしくなる(mode 000 になる)現象に遭遇しました。
最初から新しいバージョン (version 5000) で作成した zpool では、正常に tar 展開されるし、何が原因だろうか?と違いを調べたところ、あまり意識していませんでしたが、zpool のバージョンとは別に zfs のバージョンもあり、これが古いまま (version 4) であることがわかりました。
# zfs get version
NAME              PROPERTY  VALUE    SOURCE
tankX             version   4        -
きっとこれだろうと思い、zfs upgrade tankX を実行して、バージョンを 5 に上げました。そうしたところ、正常なファイルパーミッションで tar 展開できるようになりました。以上、備忘録ですが、どなたかの参考になることがあれば幸いです。
なお、ZFS on Linux を使い始めて約2年半、今回のようなデータ保全に関わるトラブルは初めてです。わたしの利用の範囲ではということですけども。

2014年11月19日水曜日

CentOS 5 + UEKr2 で XFS を利用

CentOS 5 にオラクルの UEKr2 カーネルを入れて利用しているマシンで、実験・学習目的に XFS も動かしているのですが、この環境で xfs_db が segfault していて、気持ち悪いと思っていたのですが、よくよく考えてみると、カーネルが 3.0 系(見た目のバージョンは 2.6.39)なのに対して、xfsprogs のバージョンが古い(xfsprogs-2.9.4-1.el5.centos を使ってた)ため、何か不整合が起きているのではないかと考えました。
[root@hoge ~]# dmesg | grep xfs
xfs_db[24513]: segfault at 40 ip 0000003525408dd0 sp 00007fff34d904b8 error 4 in libpthread-2.5.so[3525400000+16000]
xfs_db[28592]: segfault at 40 ip 0000003525408dd0 sp 00007fff73492348 error 4 in libpthread-2.5.so[3525400000+16000]
xfs_db[24414]: segfault at 40 ip 0000003525408dd0 sp 00007fffdcd64d58 error 4 in libpthread-2.5.so[3525400000+16000]
xfs_db[28242]: segfault at 40 ip 0000003525408dd0 sp 00007fff890c31d8 error 4 in libpthread-2.5.so[3525400000+16000]
まず、xfs_db なんぞ自分で明示的に動かした記憶がなく、調べたところ system-config-lvm を動かすと、裏で実行されるらしく、再現性を確認しました。
そして、コミュニティ最新版 xfsprogs 3.2.1 に置き換えたところ、segfault が出なくなったことを確認しました。

以下、備忘録、xfsprogs 3.2.1 のビルド手順です。どなたかのご参考まで。

1. xfsprogs-2.9.4-1.el5.centos.src.rpm をダウンロードして展開。この中の SPEC ファイルを利用する。
# rpm -ivh xfsprogs-2.9.4-1.el5.centos.src.rpm
...
# cd /usr/src/redhat/SPEC
# cp -p xfsprogs.spec xfsprogs.spec.org
2. xfsprogs-3.2.1.tar.gz をダウンロードして、/usr/src/redhat/SOURCES へコピー
# cp xfsprogs-3.2.1.tar.gz /usr/src/redhat/SOURCES
3. xfsprogs.spec を手直しする。これが少々時間を要しました。差分です。
--- xfsprogs.spec.org   2007-10-20 23:17:33.000000000 +0900
+++ xfsprogs.spec       2014-11-18 07:43:06.000000000 +0900
@@ -1,11 +1,11 @@
 Summary: Utilities for managing the XFS filesystem
 Name: xfsprogs
-Version: 2.9.4
-Release: 1%{?dist}
+Version: 3.2.1
+Release: 1.el5.staka
 License: GPL
 Group: System Environment/Base
 URL: http://oss.sgi.com/projects/xfs/
-Source0: ftp://oss.sgi.com/projects/xfs/download/cmd_tars/%{name}_%{version}-1.tar.gz
+Source0: ftp://oss.sgi.com/projects/xfs/download/cmd_tars/%{name}-%{version}.tar.gz
 Source1: xfsprogs-wrapper.h
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires: autoconf, libtool, gettext
@@ -13,7 +13,7 @@
 BuildRequires: /usr/include/uuid/uuid.h
 Provides: xfs-cmds
 Obsoletes: xfs-cmds <= %{version}
-Conflicts: xfsdump < 2.0.0
+Conflicts: xfsdump < 3.0.0
 
 %description
 A set of commands to use the XFS filesystem, including mkfs.xfs.
@@ -69,10 +69,14 @@
 rm -f $RPM_BUILD_ROOT/{%{_lib}/*.{la,a,so},%{_libdir}/*.la}
 # fix up symlink to be correct
 rm -f $RPM_BUILD_ROOT/%{_libdir}/libhandle.so
+mkdir -p $RPM_BUILD_ROOT/%{_libdir}
 ln -s ../../%{_lib}/libhandle.so.1 $RPM_BUILD_ROOT/%{_libdir}/libhandle.so
 # remove non-versioned docs location
 rm -rf $RPM_BUILD_ROOT/%{_datadir}/doc/xfsprogs/
 
+mkdir -p $RPM_BUILD_ROOT/usr/sbin
+(cd $RPM_BUILD_ROOT/sbin ; mv xfs_{admin,bmap,copy,db,estimate,freeze,fsr,growfs,info,io,logprint,mdrestore,metadump,mkfile,ncheck,quota,rtcp} ../usr/sbin)
+
 # ugly hack to allow parallel install of 32-bit and 64-bit -devel packages:
 mv -f $RPM_BUILD_ROOT%{_includedir}/xfs/platform_defs.h \
       $RPM_BUILD_ROOT%{_includedir}/xfs/platform_defs-%{_arch}.h
@@ -89,11 +93,11 @@
 
 %files -f %{name}.lang
 %defattr(-,root,root)
-%doc doc/CHANGES doc/COPYING doc/CREDITS doc/PORTING README
+%doc doc/CHANGES.gz doc/COPYING doc/CREDITS README
 /sbin/fsck.xfs
 /sbin/mkfs.xfs
 /sbin/xfs_repair
-/%{_lib}/*.so.*
+%attr(0644,root,root)   /%{_lib}/*.so.*
 %{_mandir}/man8/*
 %{_mandir}/man5/*
 %{_sbindir}/*
@@ -101,12 +105,15 @@
 %files devel
 %defattr(-,root,root)
 %{_mandir}/man3/*
-%{_includedir}/disk
+#%{_includedir}/disk
 %{_includedir}/xfs
-%{_libdir}/*.a
+#%{_libdir}/*.a
 %{_libdir}/*.so
 
 %changelog
+* Sat Nov 15 2014 s-taka  3.2.1-1
+- upgraded to upstream version 3.2.1
+
 * Sat Oct 20 2007 Johnny Hughes  2.9.4-1
 - upgraded to upstream version 2.9.4-1
 
4. RPM パッケージをビルド。
# rpmbuild -ba xfsprogs.spec
...
# ls -1 /usr/src/redhat/RPMS/x86_64/xfsprogs-*
/usr/src/redhat/RPMS/x86_64/xfsprogs-3.2.1-1.el5.staka.x86_64.rpm
/usr/src/redhat/RPMS/x86_64/xfsprogs-debuginfo-3.2.1-1.el5.staka.x86_64.rpm
/usr/src/redhat/RPMS/x86_64/xfsprogs-devel-3.2.1-1.el5.staka.x86_64.rpm
# ls -1 /usr/src/redhat/SRPMS/xfsprogs-*
/usr/src/redhat/SRPMS/xfsprogs-3.2.1-1.el5.staka.src.rpm
5. 出来上がった RPM パッケージをインストール。
# cd /usr/src/redhat/RPMS/x86_64
# rpm -Uvh xfsprogs-3.2.1-1.el5.staka.x86_64.rpm xfsprogs-devel-3.2.1-1.el5.staka.x86_64.rpm

xfsdump については、Fedora 21 のパッケージ(xfsdump-3.1.4-2.fc21.src.rpm)を利用して、CentOS 5 向けに RPM 再ビルドしました。SPEC ファイルの差分は次の通りです。
--- xfsdump.spec.org    2014-08-19 13:24:24.000000000 +0900
+++ xfsdump.spec        2014-11-15 22:11:10.000000000 +0900
@@ -1,7 +1,7 @@
 Summary: Administrative utilities for the XFS filesystem
 Name: xfsdump
 Version: 3.1.4
-Release: 2%{?dist}
+Release: 2.el5.staka
 # Licensing based on generic "GNU GENERAL PUBLIC LICENSE"
 # in source, with no mention of version.
 License: GPL+
@@ -10,7 +10,7 @@
 Source0: ftp://oss.sgi.com/projects/xfs/cmd_tars/%{name}-%{version}.tar.gz
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires: libtool, gettext, gawk
-BuildRequires: xfsprogs-devel, libuuid-devel, libattr-devel ncurses-devel
+BuildRequires: xfsprogs-devel, libattr-devel, ncurses-devel
 Requires: xfsprogs >= 2.6.30, attr >= 2.0.0
 
 %description
@@ -65,6 +65,9 @@
 %{_sharedstatedir}/xfsdump/inventory
 
 %changelog
+* Sat Nov 15 2014 s-taka  - 3.1.4-2.el5.staka
+- Rebuilt for EL5
+
 * Mon Aug 18 2014 Fedora Release Engineering  - 3.1.4-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
 

■関連記事
CentOS 5 + UEK で ZFS on Linux を利用
CentOS 5 + UEKr2 で Btrfs raid1

2014年11月13日木曜日

CentOS7 の nouveau ドライバが不安定

最近、マルチブートにしているメインマシン(ThinkPad T510)で、CentOS 7.0 を使うことが多いのですが、FireFox でブラウジングしていると、固まることが多々あり。見かけの症状から nouveau ドライバ(xorg-x11-drv-nouveau パッケージに入ってる)がイケてないのではと思ってたのですが、まじめに kdump を採取してみたとろ、次のようなメッセージが出ていました。
[root@hoge ~]# less /var/crash/127.0.0.1-2014.11.12-07:28:39/vmcore-dmesg.txt
...
[ 1258.575491] nouveau E[   PDISP][0000:01:00.0][0xc000857c][ffff88022ce71f80] channel stalled
NVIDIA のドライバに入れ替えれば、安定しそうな雰囲気なので、やってみたところ、固まる事象が解消したっぽいです。参照すると高頻度で固まってしまうページを見に行っても、落ちなくなりました。ちなみに、わたしの環境で参照するとよく固まったページは https://www.suse.com/ja-jp/documentation/sles11/singlehtml/stor_admin/raidmdadm.html こちらです。md について、なかなか良い解説が載ってます。

以下、NVIDIA ドライバへの入れ替え方法(ELRepo の kmod-nvidia 利用)。

以前、CentOS 6 および CentOS 5 で、NVIDIA ドライバを入れ替えた際には、直接 NVIDIA のサイトから Linux 向けドライバ(NVIDIA-Linux-x86_64-3xx.yy.run)をダウンロードして実行することで、dkms 形式で利用していましたが、今回は ELRepo で提供されている kmod-nvidia を利用することにしました。kmod 形式だと、カーネルアップデート時の負荷が低い(dkms だとカーネルアップデートの際に再コンパイルが走る)です。

1. ELRepo をリポジトリに追加(http://elrepo.org/tiki/tiki-index.php 参照)
[root@hoge ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[root@hoge ~]# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
2. GPU 種別判定して kmod-nvidia をインストール
[root@hoge ~]# yum install nvidia-detect
...
[root@hoge ~]# cat /sys/devices/virtual/dmi/id/product_version 
ThinkPad T510
[root@hoge ~]# nvidia-detect 
Probing for supported NVIDIA devices...
[10de:0a6c] NVIDIA Corporation GT218M [NVS 3100M]
This device requires the current 340.58 NVIDIA driver kmod-nvidia
[root@hoge ~]# yum install kmod-nvidia-304xx  ※nvidia-detect の表示を確認してバージョン選択
...
[root@hoge ~]# yum remove xorg-x11-glamor  ※共存すると不都合があるらしいので削除
...
[root@hoge ~]# ls -l /lib/modules/3.10.0-123.9.2.el7.x86_64/weak-updates/
合計 4
drwxr-xr-x. 2 root root 4096 11月 12 07:51 nvidia-304xx  ※ここに、配置される

RHEL7 / CentOS7 は、まだサーバに使うのはお勧めではない(安定性の面から 7.2 くらいまで待ったほうが良いと思う)ですが、デスクトップ環境は使い易く、居心地が良いと感じます(住めば都、慣れの問題でしょうか)。

2015-03-12追記
最近、中古で入手した ThinkPad W520 を使い始めました。このマシンの場合、nvidia-detect で最新ドライバ(kmod-nvidia)を勧められるのですが、最新ドライバを使うと、gnome terminal でのコマンド操作の際、キー入力から表示まで遅延(0.5秒くらい反応が鈍い感じになる)が起きて、不快な状態になるようです。ELRepo には、古いバージョンのドライバも用意されているので、もしやと思ってやってみたら、一番古いバージョンにしたところ、その不快な症状が出なくなりました。
[root@hoge ~]# cat /sys/devices/virtual/dmi/id/product_version 
ThinkPad W520
[root@hoge ~]# cat /etc/centos-release 
CentOS Linux release 7.0.1406 (Core)
[root@hoge ~]# lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GF106GLM [Quadro 2000M] (rev a1)
[root@hoge ~]# nvidia-detect -v
Probing for supported NVIDIA devices...
[10de:0dda] NVIDIA Corporation GF106GLM [Quadro 2000M]
This device requires the current 346.47 NVIDIA driver kmod-nvidia
[root@hoge ~]# yum search kmod-nvidia | grep ^kmod
kmod-nvidia.x86_64 : nvidia kernel module(s)
kmod-nvidia-304xx.x86_64 : nvidia-304xx kernel module(s)    ※これを使ったら遅延が起きなくなった
kmod-nvidia-340xx.x86_64 : nvidia-340xx kernel module(s)
[root@hoge ~]# rpm -qa | grep ^kmod
kmod-libs-14-9.el7.x86_64
kmod-nvidia-304xx-304.125-1.el7.elrepo.x86_64
kmod-14-9.el7.x86_64

2014年11月3日月曜日

物理セクタサイズが 4K bytes のディスクで不良セクタが発生した事例と処置

CentOS 6 + ZFS on Linux で利用している AFT の SATA HDD で、不良セクタが生じました。備忘録として、症状と処置内容を書いておきたいと思います。

当該 ZFS pool は、mirror 構成で運用しており、1ヵ月に1回のペースで scrub を実行しているのですが、ここ半年間ほど、毎度同じ HDD で ATA bus error が発生し、ZFS mirror のおかげで修復しながら(zpool status の表示が An attempt was made to correct the error. Applications are unaffected. だったので、修復されたものと判断)動いていました。
また、smartctl -A で数値変化を見ていたのですが、Raw_Read_Error_Rate が、scrub のたびに発生する ATA bus error の数だけカウントアップしており、Reallocated_Sector_Ct と Current_Pending_Sector はゼロという推移でした。

このエラーが HDD の不良なのか、はたまた、ケーブル不良や接続不良なのか、まずは切り分け試みようと、別の HDD を接続しているケーブルと交換してみたり、SATA ポートを変更してみたりしました。しかし、やはり当該 HDD のみ scrub で ATA bus error になることが分かりました。

ということから、本当に HDD 不良で間違いないようであり、このまま運用続けた場合、mirror の正常側の HDD が故障すると、データロストに至ると認知しました。

当然、処置としては別の HDD に交換するのが正しいわけで、まずは、用立てた HDD に zpool replace しました。機能は知っていたものの、本当に実行したのは初めての経験でしたが、何事もなく無事完了しました。

さて、エラーが出ていた HDD は、容量 2TB であり、結構もったいない。SecureErase したら、不良部分がリフレッシュするのではという憶測がありましたが、今回は正攻法で、smartctl でテストを行ってみることにしました。
# smartctl -t short /dev/sdXX
そうしたところ、LBA_of_first_error が表示され、不良セクタの存在が示されました。本当に、そのセクタにアクセスできないのか確かめるため、次のコマンドを実行してみたら、I/O error になりました。
# dd if=/dev/sdXX of=/dev/null bs=512 skip=<LBA_of_first_errorの値> count=1
それならば、当該セクタにゼロ書き込みすれば、修復するかもとやってみました。
# dd if=/dev/zero of=/dev/sdXX bs=512 seek=<LBA_of_first_errorの値> count=1
しかし、この書き込みは I/O error で失敗しました。それで思ったのが、この HDD は AFT だし、不良セクタも 4096 バイト単位であるはずなのではということです。確認のため、LBA_of_first_error-1 のセクタを dd で読み出したら、そこは成功。次に、LBA_of_first_error+1〜+7 の範囲のセクタを dd で読み出し試みたところ、全て失敗。さらに LBA_of_first_error+8 のセクタを読み出したら成功しました。推測通りのようであり、512 バイト単位で書き込もうとしても、Read-modify-write 動作となるために失敗するものと考えられました。そこで、次のようにして 4096 バイトを1回で書き込んだところ、サクっと成功しました。
# dd if=/dev/zero of=/dev/sdXX bs=4096 seek=$((3005239984/8)) count=1    ※値はsmartctlが示した本当の値
そして、再び smartctl -t short を実行。。。しかし、また別の LBA が表示されました。そのセクタも同様にして 4096 バイト書き込みクリア。。。さらにさらに smartctl -t short を実行。。。また別の LBA が。。。ってなことを繰り返した結果。最終的に、エラーが無くなりました。実際の smartctl の出力は次の通りです。
# smartctl -a /dev/sdXX
...
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       1127
  3 Spin_Up_Time            0x0027   238   236   021    Pre-fail  Always       -       3066
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       69
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   080   080   000    Old_age   Always       -       14706
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       68
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       20
193 Load_Cycle_Count        0x0032   153   153   000    Old_age   Always       -       141013
194 Temperature_Celsius     0x0022   111   108   000    Old_age   Always       -       41
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     14674         -
# 2  Short offline       Completed: read failure       10%     14674         3005241696
# 3  Short offline       Completed: read failure       10%     14674         3005241144
# 4  Short offline       Completed: read failure       10%     14674         3005240096
# 5  Short offline       Completed: read failure       90%     14674         3005241064
# 6  Short offline       Completed: read failure       10%     14674         3005241064
# 7  Short offline       Completed: read failure       90%     14674         3005240104
# 8  Short offline       Completed: read failure       10%     14673         3005240104
# 9  Short offline       Completed: read failure       10%     14673         3005239984
#10  Short offline       Completed: read failure       10%     14672         3005241744
#11  Short offline       Completed: read failure       90%     14672         3005239984
#12  Short offline       Completed without error       00%      8469         -
...
このディスクを使い続けるのはリスクだろうとは思いますが、もったいないので、元の ZFS mirror に attach して、三重ミラー化しました。次のような具合です。
# zpool status
...
        NAME                                                  STATE     READ WRITE CKSUM
        tankX                                                 ONLINE       0     0     0
          mirror-0                                            ONLINE       0     0     0
            ata-Hitachi_HUA723020ALA640_xxxxxxxxxxxxxx-part3  ONLINE       0     0     0
            ata-WDC_WD20EFRX-68EUZN0_WD-yyyyyyyyyyyy-part3    ONLINE       0     0     0
            ata-WDC_WD20NPVT-00Z2TT0_WD-zzzzzzzzzzzz-part3    ONLINE       0     0     0
...
3番目のディスク(WD20NPVT)が不良が生じたディスクで、2番目が交換したディスク(WD20EFRX)です。resilver はエラー無く完了済みで、その後、scrub をかけているところです。scrub でエラーが出なければ、ひとまず不良が消え去ったことになりますが、それは後日、scrub 完了してから追記したいと思います。なにせ、scrub が 24時間 くらいかかるもので。

2014-11-05追記
昨日、三重ミラー状態での scrub が完了したのですが、やはり WD20NPVT で、ATA bus error が出ており、smartctl -t short を行ったら、またも、LBA_of_first_error が表示されました。最後の手段、だめもとで SecureErase をかけてリフレッシュを試みました。2TB もの大容量HDDに SecureErase をかけたのは初めてでしたが、やはり実行時間がかなり長く、約6時間40分ほど(84MB/s程度)で無事に完了しました。その直後の smartctl -t short でも、やはり LAB_of_first_error が出ました。これはどうにもダメそうですかね。Reallocated_Sector_Ct がゼロのままだし、何かコマンドで、強制的に代替セクタに切り替えることができれば、まだ延命できるのではと思ってしまいますが。

2014-11-06追記
ダメそう(不良セクタ番号を HDD に通知して、強制的に代替セクタに切り替えるような方法がわからず)なので、三重ミラーから detach して、別の zpool を作って、copies=2 設定で利用しようかと思います。これ、話しには聞くものの、やったことの無い設定なので、実験のためにデータを充填中(コピー中)。プールの使用率が 80% 程度になったら、scrub をかけてみて、ATA bus error になっても、修復動作が動くのかどうか実験してみるつもりです。。。ただ、copies=2 のプールへの書き込みはさすがに激オソ(10MB/sくらい)になるようです。シーケンシャル READ なら 90MB/s くらいは出るようなので、iso イメージ格納とかなら、使用に耐えるものと考えられます。

2014-11-11追記
copies=2 のプールへの実験的書き込みが終わった(使用率 78%)ので、今度は scrub を実行中ですが、その前に、別のメンテで、そのサーバをシャットダウンしたのですが、そうしたところ WD20NPVT にアクセスできなくなって(device error になって)焦りました。一瞬、ぶっ壊れたのかと思ったのですが、以前にも経験したことがあるのですが、SecureErase を行った副作用で、HDD がロック状態になってしまったようでした。
# hdparm -I /dev/sdXX
...
Security: 
...
                enabled
                locked
        not     frozen
...
上のような状態になってしまっていました。解除方法は、次の通りです。
# hdparm --user-master u --security-unlock password /dev/sdXX
# hdparm --user-master u --security-disable password /dev/sdXX
この処置で、再びディスクにアクセス可能になり、scrub 実行中です。それにしても、SecureErase を行ってもロックされない HDD もあり、製品により挙動はまちまちのようです。

2014-11-12追記
さらに続きのメモですが、scrub が完了し、やっぱり途中で ATA bus error が出ているものの、zpool status では repaired だったので、copies=2 で救われたものと判断しました。その後、書き込んだデータ(実験のため Fedora/CentOS などの iso イメージを書き込みました)の md5sum チェックを行いましたが、途中でやはり ATA bus error が出たものの、md5sum 値は全て OK でした。というわけで、iso イメージ格納庫にしようかなと思案中。

2014-11-15追記
その後、書き込んだ iso イメージの md5sum チェックを何回か行いましたが、結果は全て正常値でしたので、このまま iso イメージ倉庫にしようかと思います。
その他の延命利用方法としては、今のところ ATA bus error が出るセクタ番号範囲が狭い(サイズにすると 1MB くらいの領域)ので、その部分だけ小さいパーティションで区切り、その他の正常なパーティションを md の linear モードで連結して使うという方法が考えられると思います。あるいは、LVM の運用がイヤでなければ、正常なパーティションを1つの VG にして使う方法もありそうです。

■関連記事
中古 HDD の初期確認

2014年9月2日火曜日

古い Intel ICH7 のマシンで SATA AHCI を使う方法(CentOS 6 の場合)

2005年製の古い Intel ICH7 のマシンで CentOS 6 を動かしているのですが、そのマシンの場合、HDD は SATA 接続であるものの、BIOS から AHCI や RAID モードを指定することができず、CentOS 6 からは ata_piix 配下に見えます。ata_piix だと、HDD の NCQ が使えません。
ICH7 は AHCI をサポートしているので、何か方法があるのではと思って Google 検索(キーワード:ICH7 AHCI setpci)したところ、先人の方が居られ、いじる方法はわかりました。
# setpci -s 0:1f.2 90.b=40
末尾の 40 が AHCI モードを指示することになるようです。80 だと RAID モード指示になる。
ただ、この操作を行っても、既にデバイスは ata_piix に掴まれているし、リブートすると元に戻ってしまいます(おそらく BIOS が再設定)。ネット上では grub に setpci 相当をやらせるという方法(OS の起動前にいじる方法)があるようでしたが、ふと、kexec でウォームリブートすれば、setpci で施した設定を保ったままリブートできるのではと思い、やってみたところうまくいきました。
http://docs.oracle.com/cd/E37670_01/E37355/html/ol_setup_kexec.html
こちらの runkexec スクリプトを拝借しまして、
# chown root:root /etc/init.d/runkexec
# chmod 755 /etc/init.d/runkexec
# service runkexec start
# shutdown -r now
で、AHCI に変更成功です。
setpci -s 0:1f.2 90.b=40
service runkexec start
shutdown -r now
上記内容を含むスクリプト(/root/bin/enable_ahci_and_reboot)でも書いて、運用してみたいと思います。HDD の NCQ 効果は僅かでしょうけど、なんだか得した気分( ̄ー ̄)

2014-09-07追記
grub2 のコマンドラインでは、lspci や setpci が使えるようです。ちょっとびっくり(まさか、そんなことができるとは!)。ICH7 のような古マシンで CentOS 7 を使う人は、わずかとは思いますが、例えば /etc/grub.d/15_enable_ahci に次のように書けば、ウォームリブートなどしなくても、AHCI モード変更できるようです。
#!/bin/sh
cat <<EOF
setpci -s 0:1f.2 90.b=40
EOF
# chmod 755 /etc/grub.d/15_enable_ahci
# grub2-mkconfig -o /boot/grub2/grub.cfg

2014-11-01追記
おそくなりましたが、当該マシンの lspci を確認したところ、82801GR (ICH7R) だったというオチでした。失礼しました。匿名さま、コメントをどうもありがとうございました。

2014年8月23日土曜日

IRST(インテルラピッドストレージテクノロジー)RAID0構成のWindows PCのSSD移行

お盆休みに、知人が自宅PCをSSDにしたい(HDDからSSDへ引越したい)とのことで、若干の手伝いをしたのですが、これが意外と手こずりました。せっかく得た経験値ですし、備忘録として書いておきたいと思います。

まず、Windows 7 PC ということで、Windows 7 標準のシステムバックアップツール(システムイメージの作成、システム修復ディスクによるリストア)で簡単に引っ越せるものと考えていました。同じディスクへの修復なら、以前に自分で行った経験がありました。その経験値から、SSD に収まるように C: ドライブを縮小すれば、その手が使えるものと推察したのでした。Windows 7 なら、標準のツールでボリューム縮小(パーティション縮小)が行えますし。

それで、まず、HDD がどのような構成になっているか確認させてもらったのですが・・・、意外なことに 500G HDD x 2台による IRST RAID0 構成となっていたのでした。まあでも、SSD のシングル構成に変えたとしても、Windows 7 のシステム修復処理がうまくやってくれるに違いない、、、そう思って、まずはボリューム縮小操作にとりかかったのでした。幸い C: ドライブには、そんなにデータが入っておらず、数字上は、換装する SSD の容量以下に縮小できそうでした。

ところが、Windows 7 のボリューム縮小処理では、ファイル配置のためか、目標のサイズまで縮小できませんでした。どうも、そのパーティション内で最も後ろに配置されたファイルのところまでしか圧縮できないらしいのです。Defraggler というツールで、ファイル配置を確認しました。gparted なら、ファイル移動してでも縮小してくれるのですが、おそらくですが、Windows 7 は安全を優先しているのでしょう。妥当だろうと思います。

そんなら、CentOS や Fedora の Live メディア + gparted でやればよいや、っと通常なら考えるところですが、今回は IRST の RAID0 構成というのが頭をよぎり、遠回りをしてしまいました。なんとか、ファイルの配置をうまく整える(パーティションの先頭にファイルを寄せる)ことができれば、目標のサイズにボリューム縮小できるようになるのではないかと考えたのです。

それで、いろいろな Windows 用のデフラグツール(freeなもの)を漁り、パーティションの先頭にファイルを寄せる機能がないか探したのですが、とうとう見つけられませんでした。この探索に長時間食ってしまいました。。。

気を取り直しあきらめて、勝手知ったる CentOS 6.5 LiveDVD から起動してみたところ、IRST RAID0 は、md126 に見えることが確認できました。そんなら大丈夫そうだと、EPEL から、gparted と ntfsprogs を入れ、C: ドライブを縮小したところ、なんなく成功しました。
# rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# yum install ntfsprogs  ※NTFSのパーティション操作するために必要
# yum install gparted
# gparted

パーティション縮小できたので、Windows 7 のシステムイメージ作成で、USB ディスク上にバックアップイメージを作成し、元のディスク(500G x 2)を外して、新しい SSD を接続して、システム修復ディスクから起動してリストアを実施。これでいけるだろうと思ったのですが、謎のエラーでうまくいかず。ネットで調べたところでは、バックアップ元のディスクより大きいサイズのディスクでなければ、リストアできないという仕様らしいです。( ゚ ▽ ゚ ;)なんと!! またもかなりの時間を食ってしまったのでした。

そうなると最後の手段、CentOS 6.5 LiveDVD から起動して、dd でコピーすればうまくいくだろうかと、SSD を外して、元のディスクを元のSATAポート(port0およびport1)へ再接続、SSD は空きのSATAポートへ接続して、LiveDVD から起動。sdX を取り違えないように、慎重に確認して、コピー実行。
# cat /sys/block/sdc/device/model
# dd if=/dev/md126 bs=1M | dd of=/dev/sdc bs=1M

最後に、シャットダウンして元のディスク(500G x 2台)を外し、SATA port0 に SSD を接続。。。たのみます、起動してくれっと拝みつつパワーオン。。。成功でした!! Windows 7 の起動アニメーションが表示され、無事に起動完了・引越し完了。

CentOS 6.5 なら、mdadm で IRST RAID を扱えるという知識・経験を得ることができました。これまで個人的には、Windows PC については、可能なら HW-RAID1 を使ってきましたが、PC が対応しているなら IRST RAID1 でもいいかもしれないと感じました。たぶん HW-RAID1 よりも、IRST RAID1 のほうが性能が出るでしょうから。なぜならば、NCQ が使えるだろうから。

2015-08-23追記
あれから1年、どうしても IRST マシンを使ってみたくなり、メインマシンを T510 から W520 に移行しました。これぞファイナルThinkPad!自分史上最強のマシンとなりました。こちらを参照。

2015-10-15追記
Windows の話しですが、UltraDefrag というツールのコンパクトモードという機能を使えば、パーティションの先頭にファイルを寄せることができるらしいです。試していませんが、次のページに情報がありました。
http://gigazine.net/news/20080304_ultradefrag/
それにしても、なぜあの時は、このページに辿りつかなかったんだろう。
Windows 7 の「ディスクの管理」で、ボリューム縮小操作をする時に有用かもしれません。試してないですが、備忘録まで。

2014年8月19日火曜日

物理セクタサイズが 4K bytes のディスクをミスアラインしたら、どれだけ性能劣化するのか?

最近の HDD には、物理セクタサイズが 4096 bytes で、論理セクタサイズが 512 bytes の製品(AFT と呼称されるやつ、512e とも言う)がありますが、その場合、パーティションの開始セクタ番号が 8 の倍数になるように気をつける必要があります。もし、アラインメント(alignment)がずれている場合、書き込み時に HDD 内で Read-modify-write が発生して性能劣化するはずです。
と、理屈ではわかったつもりで、今までわざわざミスアラインさせたことがありませんでしたが、実際に性能劣化する様子を見てみたいと思い、わざとミスアラインさせて、性能を測ってみました。

パーティション作成は、CentOS 7 上で行い、性能計測は Windows 7 上の CDM で実施しました。
# fdisk -u -c=dos -H 64 -S 32 /dev/sdc
でパーティション作成し、NTFS にフォーマット。

開始セクタ番号が 32 の場合。


開始セクタ番号が 63 の場合。

理論どおり、Write が落ち込んでいる様子が見てとれました。

そろそろ 4Kn (論理セクタサイズも 4096 bytes)のディスクも出てきており、種々のツールの対応も進んでいると思いますので、上記のようなミスアラインに気をつけなくてもツール(fdisk等)が、よろしくやってくれるはずではありますが、頭の片隅にメモまで。

2014年7月27日日曜日

CentOS7 の cryptsetup で AES-NI が活用されているか確認する方法

CentOS 7 の cryptsetup には、benchmark オプションが追加されており、これを利用することで、Intel CPU の AES-NI 命令が活用されているか確認できます。わたしの自宅メインマシン ThinkPad T510 (Intel Core i7 M620 2.67G) の場合のデータです。
[root@hoge ~]# grep i7 /proc/cpuinfo 
model name : Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
[root@hoge ~]# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       396586 iterations per second
PBKDF2-sha256     234057 iterations per second
PBKDF2-sha512     156410 iterations per second
PBKDF2-ripemd160  320078 iterations per second
PBKDF2-whirlpool  157349 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   639.9 MiB/s  1498.5 MiB/s
 serpent-cbc   128b    62.0 MiB/s   261.6 MiB/s
 twofish-cbc   128b   151.4 MiB/s   213.0 MiB/s
     aes-cbc   256b   493.1 MiB/s  1194.9 MiB/s
 serpent-cbc   256b    65.2 MiB/s   262.2 MiB/s
 twofish-cbc   256b   155.1 MiB/s   212.9 MiB/s
     aes-xts   256b  1351.7 MiB/s  1344.8 MiB/s
 serpent-xts   256b   230.7 MiB/s   239.1 MiB/s
 twofish-xts   256b   196.6 MiB/s   196.9 MiB/s
     aes-xts   512b  1088.9 MiB/s  1066.1 MiB/s
 serpent-xts   512b   231.7 MiB/s   240.8 MiB/s
 twofish-xts   512b   198.4 MiB/s   196.7 MiB/s
aesni_intel をロードしないようにして、計測すると、次のように数値が下がり、ちゃんと活用されている様子が確認できます。
[root@hoge ~]# grep aesni_intel /etc/modprobe.d/aes.conf 
blacklist aesni_intel
[root@hoge ~]# lsmod | grep aesni_intel
[root@hoge ~]# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       402678 iterations per second
PBKDF2-sha256     234057 iterations per second
PBKDF2-sha512     156597 iterations per second
PBKDF2-ripemd160  319687 iterations per second
PBKDF2-whirlpool  159454 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   165.1 MiB/s   187.2 MiB/s
 serpent-cbc   128b    62.3 MiB/s   263.5 MiB/s
 twofish-cbc   128b   152.1 MiB/s   214.3 MiB/s
     aes-cbc   256b   127.4 MiB/s   139.9 MiB/s
 serpent-cbc   256b    63.4 MiB/s   264.3 MiB/s
 twofish-cbc   256b   155.8 MiB/s   213.9 MiB/s
     aes-xts   256b   187.5 MiB/s   185.2 MiB/s
 serpent-xts   256b   231.2 MiB/s   242.4 MiB/s
 twofish-xts   256b   197.7 MiB/s   197.7 MiB/s
     aes-xts   512b   140.6 MiB/s   140.8 MiB/s
 serpent-xts   512b   232.0 MiB/s   242.6 MiB/s
 twofish-xts   512b   199.1 MiB/s   197.6 MiB/s
この数値だと、SSD 等の高速なディスクに LUKS で暗号化してデータ格納するなら、AES-NI(Intel CPU の暗号化支援命令)によりスループットが大幅に向上しそうですね。

2014年7月16日水曜日

CentOS7 使いはじめメモ

現在書きかけです。

RHEL7.0 RC を弄って、少し探ってはいましたが、CentOS 7.0 をサーバ利用し始めるにあたり、自分なりの勘所をまとめてみようと思います。

■インストール開始前に考えること(2014-07-16)
CentOS 6 以下でも、OS ディスクのパーティション構成、割り当てサイズについては考えていたわけですが、CentOS 7 ではファイルシステムの選択肢が増えているために、どれにしようか迷うかもしれません。選択肢は3つ XFS(デフォルト), Ext4, Btrfs(まだTechnology Preview) あります。
また、LVM を使うか否かも考慮事項ですが、新しく LVM のシンプロビジョニングを利用することもできます。
さらに、ソフトウェア RAID は md ではなく、Btrfs の RAID 機能を利用できます。Btrfs は、データとメタデータのチェックサム機能を備えており、RAID 機能を利用すれば、md を越える耐障害性を発揮できる(はず)です。・・・でも Red Hat 社は、RHEL7.0 では、まだ Btrfs は Technology Preview と言ってますので、リスクが高いと考えられます。Btrfs は、透過圧縮機能も魅力なのですが。

■ファイルシステムはどれにしたらいいか?(2015-01-22追記)
レッドハット社は XFS を推してますが、わたしとしては、OS 領域については、ext4 でよいのではと考えます。CentOS 6(または RHEL6)以下の利用経験があれば、その経験値(システムバックアップのノウハウなど)を使える点からの選択です。もしも、RHEL7+商用サポートサービス(N社やF社など)を利用するならどうかというと、やはり ext4 を選択するのがよかろうと思います。ext4 ならば、障害事例やノウハウが商用サポートベンダに、豊富に蓄積されていることが期待でき、従って、トラブル発生時の対応時間が XFS よりは短くて済むと考えられるためです。
さて、次にデータ領域のファイルシステムをどうするかということですが、だいたい5年先(たいていのサーバの利用年数はこのくらいでは)を考えて、データ量が 16TB を越えることが予想されるのであれば、XFS を選択すれば良いだろうと思います。ext4 上に既存データがあり、そのデータ量が5年先でも 16TB を越えそうにないのならば、RHEL7系に移行しても、引き続き ext4 を使うのが良いのではと思います。現在の ext4 ならば、ブロックサイズを 4K を越える値(例えば 8K)にすることで、16TB を越えられるはずですが、この使用形態は商用実績がほとんど無いものと考えられるので、リスクが高いと思われます。
2015-01-25追記、認識が間違っていたようで、ブロックサイズは 4K のままのようです。こちらを参照。

2014-11-12追記
まとめようと思いつつ放っているが、過去の経験上、安定志向ならば RHEL7.2 あたりから使ったほうが良いだろうと思う。あくまで個人的感触。

2015-04-23追記
RHEL7.1/CentOS7.1 がリリース済みですが、期待の Btrfs は、引き続きTechnology Previewのままでした。

2015-09-05追記
RHEL7.2 Beta のリリースノートが公開されましたが、期待の Btrfs は、今回もTechnology Previewのままでした。
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/7.2_Release_Notes/index.html
ですが、カーネルのchangelogを眺めてみると、精力的に取り組んでいる様子が伺えます。RHEL6系カーネルのほうのchangelogには Btrfs: がぽつぽつとしか出てきませんので、見比べればわかります。

2015-11-23追記
RHEL7.2 がリリースされたようですが、やっぱり Btrfs は Technology Preview でした。
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/7.2_Release_Notes/index.html

2014年7月5日土曜日

Perlのprintf("%d")の落とし穴

古いマシンで、32bit版のCentOS6を使っているのですが、その環境で手持ちのPerlスクリプトの出力値がおかしく(負値になる)、つまるところ2Gを越える整数値をprintf("%d")で表示しようとすると、オーバーフローするためのようでした。
[root@hoge ~]# cat /etc/redhat-release 
CentOS release 6.4 (Final)
[root@hoge ~]# uname -p
i686
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024;printf("%d\n",$a*$b);'
1073741824
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*2;printf("%d\n",$a*$b);'
-2147483648
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*3;printf("%d\n",$a*$b);'
-1073741824
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*4;printf("%d\n",$a*$b);'
-1
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*5;printf("%d\n",$a*$b);'
-1
現象はわかりましたが、ちゃんと表示できるようにするにはどうしたらいいのか、しばし格闘したのち、%sを使えば、よきに計らってくれることがわかりました。Perlよ、ありがとう。
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*2;printf("%s\n",$a*$b);'
2147483648
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*3;printf("%s\n",$a*$b);'
3221225472
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*4;printf("%s\n",$a*$b);'
4294967296
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*5;printf("%s\n",$a*$b);'
5368709120
あるいは、いったん変数に入れれば、次のように書けます。場合によっては、こちらのほうがいいかも。
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*2;$c=$a*$b;print("$c\n");'
2147483648
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*3;$c=$a*$b;print("$c\n");'
3221225472
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*4;$c=$a*$b;print("$c\n");'
4294967296
[root@hoge ~]# perl -e '$a=1024*1024;$b=1024*5;$c=$a*$b;print("$c\n");'
5368709120
もちろん、64bit環境では%dであっても、負にはなりません。

2014年5月8日木曜日

bash でシェル変数が定義されているかを判定する方法は?

bash でシェル変数が(nullかどうかではなくて)定義されているかを判定したいと思って、調べたのですが、エレガントな方法がみつかりませんでした。

最初は、
if [ "${VAR:-UNDEF}" = "UNDEF" ] ; then
    ...
fi
だろうかと思ったのですが、VAR="" の時も真となってしまうので、微妙に違いました。それと、実際には無いはずとしても VAR="UNDEF" だったら、意図しない状況になってしまうのが引っかかります。処理内容によってはセキュリティホールのタネにもなるのではないか。

書籍調査/ネット検索の末に、
if ! set | grep -m 1 -q ^VAR= ; then
    ... # VARが未定義の場合に行う処理を記述
fi
とするしかなさそうなのですが、もっとエレガントな方法は無いものでしょうかね。現在のマシンでは大した処理コストではないですが、目的に対しては仰仰しいと思いました。
bash にそういった機能(isset のような)があったらいいように思いますが、需要がほとんどないし不要ということだろうか。

2014-05-10追記
匿名様(コメント参照)から情報頂き、
if [ -z "${VAR+x}" ] ; then    # VARが定義済み(nullを含む)の場合 x が返るので、-z でテストすれば OK
    ... # VARが未定義の場合に行う処理を記述
fi
と書けると知りました。少々難しい(慣れの問題?)ですが、手短に書けて良いでね。

2014-05-17追記
RHEL7.0 RC を調べていて、[ -v VAR ] が追加されているのを見つけました。
[root@hoge ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.0 (Maipo)
[root@hoge ~]# bash --version
GNU bash, バージョン 4.2.45(1)-release (x86_64-redhat-linux-gnu)
...
[root@hoge ~]# help test
...
    Other operators:
    
      -o OPTION      True if the shell option OPTION is enabled.
      -v VAR  True if the shell variable VAR is set
...
bash の CHANGES を確認してみると、バージョン 4.2 で追加されたようです。
------------------------------------------------------------------------------
This document details the changes between this version, bash-4.2-alpha,
and the previous version, bash-4.1-release.
...
3.  New Features in Bash
...
f.  test/[/[[ have a new -v variable unary operator, which returns success if
    `variable' has been set.
...
いちおう動作確認です。
[root@hoge ~]# VAR="set" ; [ -v VAR ] ; echo $?
0
[root@hoge ~]# unset VAR ; [ -v VAR ] ; echo $?
1
RHEL6/CentOS6 以下の bash では使えないので、当面は利用できないですが、メモまで。

2014年4月29日火曜日

RHEL7.0 RC で、最新の ZFS on Linux を試してみた

Red Hat Network 上に RHEL7.0 RC が公開されたので、早速 ZFS を試してみました。
以下、メモです。

まず、dkms が必要ですが、これは EPEL の RHEL6/CentOS6 向けリポジトリから、.src.rpm を取ってきて再ビルドしてインストールしました。
# rpmbuild --rebuild dkms-2.2.0.3-20.el6.src.rpm
# ls /root/rpmbuild/RPMS/noarch
dkms-2.2.0.3-20.el7.noarch.rpm
# rpm -ivh /root/rpmbuild/RPMS/noarch/dkms-2.2.0.3-20.el7.noarch.rpm
つぎに、ZFS をインストールします。もちろん、RHEL7/CentOS7 向けのリポジトリは、まだありませんので、GitHub から最新のソースを取り出してビルドしました。
手順は以下のような感じです。
# mkdir zfs_on_linux
# cd zfs_on_linux
# git clone https://github.com/zfsonlinux/spl.git
# git clone https://github.com/zfsonlinux/zfs.git

# cd spl
# autoreconf -i  ※configureを生成するため、この操作が必要
# ./configure --with-config=user
# make rpm-utils rpm-dkms

# cd ../zfs
# autoreconf -i
# ./configure --with-config=user
# make rpm-utils rpm-dkms

# cd ..
# ls -1 spl/*.rpm
spl/spl-0.6.2-33_g89aa970.el7.src.rpm
spl/spl-0.6.2-33_g89aa970.el7.x86_64.rpm
spl/spl-debuginfo-0.6.2-33_g89aa970.el7.x86_64.rpm
spl/spl-dkms-0.6.2-33_g89aa970.el7.noarch.rpm
spl/spl-dkms-0.6.2-33_g89aa970.el7.src.rpm
# ls -1 zfs/*.rpm
zfs/zfs-0.6.2-259_gde39ec1.el7.src.rpm
zfs/zfs-0.6.2-259_gde39ec1.el7.x86_64.rpm
zfs/zfs-debuginfo-0.6.2-259_gde39ec1.el7.x86_64.rpm
zfs/zfs-devel-0.6.2-259_gde39ec1.el7.x86_64.rpm
zfs/zfs-dkms-0.6.2-259_gde39ec1.el7.noarch.rpm
zfs/zfs-dkms-0.6.2-259_gde39ec1.el7.src.rpm
zfs/zfs-dracut-0.6.2-259_gde39ec1.el7.x86_64.rpm
zfs/zfs-test-0.6.2-259_gde39ec1.el7.x86_64.rpm

# yum localinstall spl/spl-0.6.2-33_g89aa970.el7.x86_64.rpm \
spl/spl-dkms-0.6.2-33_g89aa970.el7.noarch.rpm \
zfs/zfs-0.6.2-259_gde39ec1.el7.x86_64.rpm \
zfs/zfs-dkms-0.6.2-259_gde39ec1.el7.noarch.rpm \
zfs/zfs-dracut-0.6.2-259_gde39ec1.el7.x86_64.rpm \
zfs/zfs-test-0.6.2-259_gde39ec1.el7.x86_64.rpm 
で、試運転結果です。
# 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
# zpool import tank4
# zpool list tank4
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank4   368G   283G  84.5G    77%  1.00x  ONLINE  -
# zpool get all tank4
NAME   PROPERTY               VALUE                  SOURCE
tank4  size                   368G                   -
tank4  capacity               77%                    -
tank4  altroot                -                      default
tank4  health                 ONLINE                 -
tank4  guid                   1893700132493715388    default
tank4  version                -                      default
tank4  bootfs                 -                      default
tank4  delegation             on                     default
tank4  autoreplace            off                    default
tank4  cachefile              -                      default
tank4  failmode               wait                   default
tank4  listsnapshots          off                    default
tank4  autoexpand             off                    default
tank4  dedupditto             0                      default
tank4  dedupratio             1.00x                  -
tank4  free                   84.5G                  -
tank4  allocated              283G                   -
tank4  readonly               off                    -
tank4  ashift                 12                     local
tank4  comment                -                      default
tank4  expandsize             0                      -
tank4  freeing                0                      default
tank4  feature@async_destroy  enabled                local
tank4  feature@empty_bpobj    active                 local
tank4  feature@lz4_compress   active                 local
# zpool status tank4
  pool: tank4
 state: ONLINE
  scan: scrub repaired 12.1G in 1h34m with 0 errors on Sat Apr 26 12:37:25 2014
config:

 NAME                                                        STATE     READ WRITE CKSUM
 tank4                                                       ONLINE       0     0     0
   mirror-0                                                  ONLINE       0     0     0
     ata-HITACHI_HTS725050A9A364_xxxxxxxxxxxxxxxxxxxx-part1  ONLINE       0     0     0
     ata-HGST_HTS721010A9E630_yyyyyyyyyyyyyy-part1           ONLINE       0     0     0

errors: No known data errors
気になる性能は、どうかというと。
# 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
# zfs set compression=off tank4/backup
# cd /tank4/backup
# ls -l sda6.tar 
-rw-r--r-- 1 root root 10927441920 10月 20  2013 sda6.tar
# time tar xf sda6.tar 

real 3m23.413s
user 0m3.932s
sys 0m57.623s
# time rm -rf test.restore

real 0m9.153s
user 0m0.167s
sys 0m8.924s
にわかには信じ難いほど速くなってました!\(^0^)/
ピンと来ない方は、こちら を参照。同じマシン上に、RHEL7.0 RC のマルチブート環境を用意して、実験しています。
ちなみに、RHEL7 のデフォルトのファイルシステムは XFS ですが、マルチブートと相性が悪いのと、SSD 節約のため、Btrfs (compress-force=lzo) を使いました。Btrfs にインストールする手順は、こちら を参照。

2014-05-05追記
el7 向けの EPEL beta が既に公開されているので、dkms はそちらからインストールすれば済みます。

2014-06-17追記
別途用意した RHEL7 + ZOL 0.6.3 環境にて、SELinux をデフォルトの Enforcing にしたまま、tar の展開/削除を試したら、zfs_iput_taskq が大量に CPU 消費して、焦りました。
https://github.com/zfsonlinux/zfs/issues/1953 こちらの現象のようでした。RoadMap 上 0.6.5 で修正目標のようです。
もし、どうしても SELinux が必要なマシンで ZFS 使う方は、お気をつけて。

2014年3月22日土曜日

ZFS on Linux の vdev_id

ZFS on Linux が認識するデバイスパスは、デフォルトでは /dev/disk/by-id が使われます。次のような具合です。
[root@hoge ~]# uname -a
Linux hoge 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# zpool status
  pool: tank4
 state: ONLINE
  scan: scrub repaired 0 in 1h18m with 0 errors on Sat Mar 15 20:39:47 2014
config:

 NAME                                                        STATE     READ WRITE CKSUM
 tank4                                                       ONLINE       0     0     0
   mirror-0                                                  ONLINE       0     0     0
     ata-HITACHI_HTS725050A9A364_xxxxxxxxxxxxxxxxxxxx-part1  ONLINE       0     0     0
     ata-HGST_HTS721010A9E630_yyyyyyyyyyyyyy-part1           ONLINE       0     0     0

errors: No known data errors
[root@hoge ~]# ls -l /dev/disk/by-id/ata-H*-part1
lrwxrwxrwx 1 root root 10 Mar 22 15:24 /dev/disk/by-id/ata-HGST_HTS721010A9E630_yyyyyyyyyyyyyy-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Mar 22 15:24 /dev/disk/by-id/ata-HITACHI_HTS725050A9A364_xxxxxxxxxxxxxxxxxxxx-part1 -> ../../sdc1
sdX なんかを使ってはよろしくない(ずれるから)のは分かりますが、どうにも長くて、特に同じ種類のディスクを使っていると個体を識別し難い(何番目のベイのディスクか不明瞭)と思っていました。
ZFS on Linux には、vdev_id というツールが用意されていて、この長いパスに別名(alias)を付与することができるようです。/etc/zfs/vdev_id.conf に次のように指定します。
#     by-vdev
#     name     fully qualified or base name of device link
alias  HITACHI_500G  ata-HITACHI_HTS725050A9A364_xxxxxxxxxxxxxxxxxxxx
alias  HGST___1000G  ata-HGST_HTS721010A9E630_yyyyyyyyyyyyyy
設定して再起動すると、/dev/disk/by-vdev というデバイスパスが生成されるようになります。
[root@hoge ~]# ls -l /dev/disk/by-vdev/H*-part1
lrwxrwxrwx 1 root root 10 Mar 22 15:24 /dev/disk/by-vdev/HGST___1000G-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Mar 22 15:24 /dev/disk/by-vdev/HITACHI_500G-part1 -> ../../sdc1
いったんプールを export してから、-d オプションを使って import し直せば、この便利な名前が使われるようになります。
[root@hoge ~]# zpool export tank4
[root@hoge ~]# zpool import -d /dev/disk/by-vdev tank4
[root@hoge ~]# zpool status tank4
  pool: tank4
 state: ONLINE
  scan: scrub repaired 0 in 1h18m with 0 errors on Sat Mar 15 20:39:47 2014
config:

 NAME                    STATE     READ WRITE CKSUM
 tank4                   ONLINE       0     0     0
   mirror-0              ONLINE       0     0     0
     HITACHI_500G-part1  ONLINE       0     0     0
     HGST___1000G-part1  ONLINE       0     0     0

errors: No known data errors
うまく名前を付与すれば物理的な接続(SATA portの何番に接続したディスクか?ベイの何段目のディスクか?等)も表現できて便利と思います。短めの名前をつければ、コンソール画面(横80桁)での操作時に、折り返し表示にならずに済むことにもなります。

2014年3月16日日曜日

3つのOSでZFSの性能を比較

以前にも測定したことがありますが、最近 FreeBSD 10.0 がリリースされたので、日常的操作(コピー、シーケンシャルREAD)で性能比較を行ってみました。
2015-04-18追記、ふたたび比較実験しました。

比較は、
・CentOS 6.5 + ZFS on Linux 0.6.2
・OpenIndiana 151a9
(最近ひっそりとアップデートされた。ただし iso 提供は無し)
・FreeBSD 10.0
の3つの OS で行いました。マシン環境は次の通りです。3つの OS をマルチブートできるようにしてあります。

・lenovo ThinkPad T510
・CPU Intel Core i7 M620 2.67GHz
・MEM 8GB
・OS ディスク R2021D
(Plextor M5M 256GB SSD 2枚によるRAID1)
・ZFS pool (HGST HTS721010A9E630 7200rpm SATA 1TB +
 HITACHI HTS725050A9A634 7200rpm SATA 500GB による mirror構成)
 ※補足:HGST 1T を 2nd HDD ベイに搭載、HITACHI 500G は eSATA 接続で、約400G のパーティションでミラー

まずは、ファイルコピーです。実験データには、CentOS 6 の OS バックアップイメージを使っています。
root@hoge:~# uname -a
SunOS hoge 5.11 oi_151a9 i86pc i386 i86pc Solaris
root@hoge:~# zpool import tank4
root@hoge:~# zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT
rpool  11.6G  9.57G  2.06G         -    82%  1.00x  ONLINE  -
tank4   368G   268G  99.7G         -    72%  1.00x  ONLINE  -
root@hoge:~# zpool status tank4
  pool: tank4
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
 still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
 the pool may no longer be accessible by software that does not support
 the features. See zpool-features(5) for details.
  scan: scrub repaired 0 in 1h18m with 0 errors on Sat Mar 15 20:39:47 2014
config:

 NAME          STATE     READ WRITE CKSUM
 tank4         ONLINE       0     0     0
   mirror-0    ONLINE       0     0     0
     c5t3d0p1  ONLINE       0     0     0
     c5t1d0p1  ONLINE       0     0     0

errors: No known data errors
root@hoge:~# cd /tank4/backup
root@hoge:/tank4/backup# ls -l m5m.sda6.dump 
-rw-r--r-- 1 root root 9207209203 2014-02-22 21:51 m5m.sda6.dump
root@hoge:/tank4/backup# cp m5m.sda6.dump m5m.sda6.dump-copied-on-oi151a9

real 3m44.857s
user 0m0.056s
sys 0m16.702s
root@hoge:/tank4/backup# ls -l m5m.sda6.dump*
-rw-r--r-- 1 root root 9207209203 2014-02-22 21:51 m5m.sda6.dump
-rw-r--r-- 1 root root 9207209203 2014-03-16 13:55 m5m.sda6.dump-copied-on-oi151a9
root@hoge:/tank4/backup# cd
root@hoge:~# zpool export tank4
root@hoge:~ # uname -a
FreeBSD hoge 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@hoge:~ # zpool import tank4
root@hoge:~ # zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank4   368G   277G  91.1G    75%  1.00x  ONLINE  -
root@hoge:~ # zpool status
  pool: tank4
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
 still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
 the pool may no longer be accessible by software that does not support
 the features. See zpool-features(7) for details.
  scan: scrub repaired 0 in 1h18m with 0 errors on Sat Mar 15 20:39:47 2014
config:

 NAME                                    STATE     READ WRITE CKSUM
 tank4                                   ONLINE       0     0     0
   mirror-0                              ONLINE       0     0     0
     diskid/DISK-xxxxxxxxxxxxxxxxxxxxs1  ONLINE       0     0     0
     diskid/DISK-yyyyyyyyyyyyyys1        ONLINE       0     0     0

errors: No known data errors
root@hoge:~ # cd /tank4/backup
root@hoge:/tank4/backup # ls -l m5m*
-rw-r--r--  1 root  wheel  9207209203 Feb 22 21:51 m5m.sda6.dump
-rw-r--r--  1 root  wheel  9207209203 Mar 16 13:55 m5m.sda6.dump-copied-on-oi151a9
root@hoge:/tank4/backup # time cp m5m.sda6.dump m5m.sda6.dump-copied-on-freebsd10.0
0.007u 4.455s 4:14.75 1.7% 21+174k 70801+2io 0pf+0w
root@hoge:/tank4/backup # ls -l m5m*
-rw-r--r--  1 root  wheel  9207209203 Feb 22 21:51 m5m.sda6.dump
-rw-r--r--  1 root  wheel  9207209203 Mar 16 14:09 m5m.sda6.dump-copied-on-freebsd10.0
-rw-r--r--  1 root  wheel  9207209203 Mar 16 13:55 m5m.sda6.dump-copied-on-oi151a9
root@hoge:/tank4/backup # cd
root@hoge:~ # zpool export tank4
[root@hoge ~]# uname -a
Linux hoge 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# zpool import tank4
[root@hoge ~]# zpool status
  pool: tank4
 state: ONLINE
  scan: scrub repaired 0 in 1h18m with 0 errors on Sat Mar 15 20:39:47 2014
config:

 NAME                                                        STATE     READ WRITE CKSUM
 tank4                                                       ONLINE       0     0     0
   mirror-0                                                  ONLINE       0     0     0
     ata-HITACHI_HTS725050A9A364_xxxxxxxxxxxxxxxxxxxx-part1  ONLINE       0     0     0
     ata-HGST_HTS721010A9E630_yyyyyyyyyyyyyy-part1           ONLINE       0     0     0

errors: No known data errors
[root@hoge ~]# zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank4   368G   285G  82.6G    77%  1.00x  ONLINE  -
[root@hoge ~]# cd /tank4/backup
[root@hoge backup]# ls -l m5m*
-rw-r--r-- 1 root root 9207209203 Feb 22 21:51 m5m.sda6.dump
-rw-r--r-- 1 root root 9207209203 Mar 16 14:09 m5m.sda6.dump-copied-on-freebsd10.0
-rw-r--r-- 1 root root 9207209203 Mar 16 13:55 m5m.sda6.dump-copied-on-oi151a9
[root@hoge backup]# time cp m5m.sda6.dump m5m.sda6.dump-copied-on-centos6

real 3m29.308s
user 0m0.038s
sys 0m6.764s
[root@hoge backup]# ls -l m5m*
-rw-r--r-- 1 root root 9207209203 Feb 22 21:51 m5m.sda6.dump
-rw-r--r-- 1 root root 9207209203 Mar 16 14:21 m5m.sda6.dump-copied-on-centos6
-rw-r--r-- 1 root root 9207209203 Mar 16 14:09 m5m.sda6.dump-copied-on-freebsd10.0
-rw-r--r-- 1 root root 9207209203 Mar 16 13:55 m5m.sda6.dump-copied-on-oi151a9
[root@hoge backup]# zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank4   368G   294G  74.0G    79%  1.00x  ONLINE  -

次に、シーケンシャルREAD (ddコマンド利用) です。
キャッシュの影響を避けるため、再起動&zpool import 直後に実行しています。
root@hoge:~# uname -a
SunOS hoge 5.11 oi_151a9 i86pc i386 i86pc Solaris
root@hoge:~# dd if=/tank4/backup/m5m.sda6.dump-copied-on-oi151a9 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes (9.2 GB) copied, 106.582 s, 86.4 MB/s
root@hoge:~# dd if=/tank4/backup/m5m.sda6.dump-copied-on-freebsd10.0 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes (9.2 GB) copied, 115.16 s, 80.0 MB/s
root@hoge:~# dd if=/tank4/backup/m5m.sda6.dump-copied-on-centos6 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes (9.2 GB) copied, 114.334 s, 80.5 MB/s
root@hoge:~ # uname -a
FreeBSD hoge 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@hoge:~ # dd if=/tank4/backup/m5m.sda6.dump-copied-on-oi151a9 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes transferred in 105.113849 secs (87592732 bytes/sec)
root@hoge:~ # dd if=/tank4/backup/m5m.sda6.dump-copied-on-freebsd10.0 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes transferred in 114.760721 secs (80229621 bytes/sec)
root@hoge:~ # dd if=/tank4/backup/m5m.sda6.dump-copied-on-centos6 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes transferred in 113.732792 secs (80954745 bytes/sec)
[root@hoge ~]# uname -a
Linux hoge 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# dd if=/tank4/backup/m5m.sda6.dump-copied-on-oi151a9 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes (9.2 GB) copied, 64.9959 s, 142 MB/s
[root@hoge ~]# dd if=/tank4/backup/m5m.sda6.dump-copied-on-freebsd10.0 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes (9.2 GB) copied, 71.2292 s, 129 MB/s
[root@hoge ~]# dd if=/tank4/backup/m5m.sda6.dump-copied-on-centos6 of=/dev/null bs=1M
8780+1 records in
8780+1 records out
9207209203 bytes (9.2 GB) copied, 72.7268 s, 127 MB/s

1ユーザのパーソナル利用環境での数値ですし、参考までですが、実験したワークロードにおいては、CentOS が良好な結果となりました。

あと2点補足ですが、ZFS のチューニング (ARCサイズ調整等) は行っていないデフォルトでの実験結果です。 また、当該 ZFS 領域には圧縮オプションは指定していません。
プールのプロパティを示します。
[root@hoge ~]# zpool get all tank4
NAME   PROPERTY               VALUE                  SOURCE
tank4  size                   368G                   -
tank4  capacity               79%                    -
tank4  altroot                -                      default
tank4  health                 ONLINE                 -
tank4  guid                   1893700132493715388    default
tank4  version                -                      default
tank4  bootfs                 -                      default
tank4  delegation             on                     default
tank4  autoreplace            off                    default
tank4  cachefile              -                      default
tank4  failmode               wait                   default
tank4  listsnapshots          off                    default
tank4  autoexpand             off                    default
tank4  dedupditto             0                      default
tank4  dedupratio             1.00x                  -
tank4  free                   74.0G                  -
tank4  allocated              294G                   -
tank4  readonly               off                    -
tank4  ashift                 12                     local
tank4  comment                -                      default
tank4  expandsize             0                      -
tank4  freeing                0                      default
tank4  feature@async_destroy  enabled                local
tank4  feature@empty_bpobj    active                 local
tank4  feature@lz4_compress   active                 local
[root@hoge ~]# zfs get all tank4/backup
NAME          PROPERTY              VALUE                  SOURCE
tank4/backup  type                  filesystem             -
tank4/backup  creation              Sat Feb  1  9:43 2014  -
tank4/backup  used                  66.4G                  -
tank4/backup  available             67.2G                  -
tank4/backup  referenced            66.4G                  -
tank4/backup  compressratio         1.00x                  -
tank4/backup  mounted               yes                    -
tank4/backup  quota                 none                   default
tank4/backup  reservation           none                   default
tank4/backup  recordsize            128K                   default
tank4/backup  mountpoint            /tank4/backup          default
tank4/backup  sharenfs              off                    default
tank4/backup  checksum              on                     default
tank4/backup  compression           off                    local
tank4/backup  atime                 off                    inherited from tank4
tank4/backup  devices               on                     default
tank4/backup  exec                  on                     default
tank4/backup  setuid                on                     default
tank4/backup  readonly              off                    default
tank4/backup  zoned                 off                    default
tank4/backup  snapdir               hidden                 default
tank4/backup  aclinherit            restricted             default
tank4/backup  canmount              on                     default
tank4/backup  xattr                 on                     default
tank4/backup  copies                1                      default
tank4/backup  version               4                      -
tank4/backup  utf8only              off                    -
tank4/backup  normalization         none                   -
tank4/backup  casesensitivity       sensitive              -
tank4/backup  vscan                 off                    default
tank4/backup  nbmand                off                    default
tank4/backup  sharesmb              off                    default
tank4/backup  refquota              none                   default
tank4/backup  refreservation        none                   default
tank4/backup  primarycache          all                    default
tank4/backup  secondarycache        all                    default
tank4/backup  usedbysnapshots       0                      -
tank4/backup  usedbydataset         66.4G                  -
tank4/backup  usedbychildren        0                      -
tank4/backup  usedbyrefreservation  0                      -
tank4/backup  logbias               latency                default
tank4/backup  dedup                 off                    default
tank4/backup  mlslabel              none                   default
tank4/backup  sync                  standard               default
tank4/backup  refcompressratio      1.00x                  -
tank4/backup  written               66.4G                  -
tank4/backup  snapdev               hidden                 default

なお、手持ちデータがありませんので、ここ2年ほど ZFS on Linux を使ってみた経験上の話しですが、多数のファイルを含む tar ファイルの展開のような、メタデータ処理が多いワークロードは、ext4 等と比べて苦手なようです。あと、NFS はかなり苦手(ZIL使わない/使えない場合)のようで、NFS export する場合は、ZVOL + ext4 として export すると良い結果が得られると思います。ZVOL でも圧縮機能や snapshot を使えるので有益ですし、オンラインで割り当てサイズ (volsize) 拡張することも可能です。

2014-03-23追記
tar の展開についても比較してみました。展開に使ったアーカイブは、btrfs の実験に使ったものと同じです。
root@hoge:~# uname -a
SunOS hoge 5.11 oi_151a9 i86pc i386 i86pc Solaris
root@hoge:~# zpool import tank4
root@hoge:~# cd /tank4/backup
root@hoge:/tank4/backup# ls -l sda6.tar
-rw-r--r-- 1 root root 10927441920 2013-10-20 22:44 sda6.tar
root@hoge:/tank4/backup# time tar xf sda6.tar

real    4m2.966s
user    0m4.219s
sys     1m8.711s
root@hoge:/tank4/backup# time rm -rf test.restore

real    0m27.575s
user    0m0.495s
sys     0m7.178s
root@hoge:/tank4/backup# cd
root@hoge:~# zpool export tank4
root@hoge:~ # uname -a
FreeBSD hoge 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@hoge:~ # zpool import tank4
root@hoge:~ # cd /tank4/backup
backup/  backup2/ backup3/
root@hoge:~ # cd /tank4/backup
root@hoge:/tank4/backup # ls -l sda6.tar
-rw-r--r--+ 1 root  wheel  10927441920 Oct 20 22:44 sda6.tar
root@hoge:/tank4/backup # time tar xf sda6.tar
3.651u 29.506s 5:08.18 10.7%    66+173k 59704+418539io 12pf+0w
root@hoge:/tank4/backup # time rm -rf test.restore
0.336u 12.340s 1:09.05 18.3%    15+165k 26766+0io 0pf+0w
root@hoge:/tank4/backup # cd
root@hoge:~ # zpool export tank4
[root@hoge ~]# uname -a
Linux hoge 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# zpool import tank4
[root@hoge ~]# cd /tank4/backup
[root@hoge backup]# ls -l sda6.tar
-rw-r--r-- 1 root root 10927441920 Oct 20 22:44 sda6.tar
[root@hoge backup]# time tar xf sda6.tar

real    3m51.565s
user    0m3.033s
sys     0m46.419s
[root@hoge backup]# time rm -rf test.restore

real    2m1.249s
user    0m0.471s
sys     0m16.205s
[root@hoge backup]# cd
[root@hoge ~]# zpool export tank4
この実験では、CentOS は、削除(rm)が苦手という結果になりました。現在の Linux 実装は、vmalloc に依存しており(meminfo を見ればわかります)、そこら辺に性能が出ない原因があるのではと思いますが、将来は他の Linux の fs と同様にページキャッシュを使う構造になるはず(既に試みが行われている)であり、まだ、性能向上の余地が残っているということでもあろうと思います。

2014-03-25追記
ものはついでに、LZ4 圧縮を有効にした場合についても、やってみました。
root@hoge:~# uname -a
SunOS hoge 5.11 oi_151a9 i86pc i386 i86pc Solaris
root@hoge:~# zpool import tank4
root@hoge:~# zpool list tank4
NAME    SIZE  ALLOC   FREE  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT
tank4   368G   271G  96.7G         -    73%  1.00x  ONLINE  -
root@hoge:~# zfs list tank4/backup
NAME           USED  AVAIL  REFER  MOUNTPOINT
tank4/backup  72.8G  89.9G  72.8G  /tank4/backup
root@hoge:~# zfs get compression tank4/backup
NAME          PROPERTY     VALUE     SOURCE
tank4/backup  compression  off       local
root@hoge:~# zfs set compression=lz4 tank4/backup
root@hoge:~# zfs get compression tank4/backup
NAME          PROPERTY     VALUE     SOURCE
tank4/backup  compression  lz4       local
root@hoge:~# cd /tank4/backup
root@hoge:/tank4/backup# ls -l sda6.tar 
-rw-r--r-- 1 root root 10927441920 2013-10-20 22:44 sda6.tar
root@hoge:/tank4/backup# time tar xf sda6.tar 

real 2m40.653s
user 0m4.100s
sys 0m50.868s
root@hoge:/tank4/backup# time rm -rf test.restore

real 0m15.588s
user 0m0.425s
sys 0m6.385s
root@hoge:/tank4/backup# cd
root@hoge:~# zpool export tank4
root@hoge:~ # uname -a
FreeBSD hoge 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@hoge:~ # zpool import tank4
root@hoge:~ # zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank4   368G   271G  96.7G    73%  1.00x  ONLINE  -
root@hoge:~ # zfs list tank4/backup
NAME           USED  AVAIL  REFER  MOUNTPOINT
tank4/backup  72.8G  89.9G  72.8G  /tank4/backup
root@hoge:~ # zfs get compression tank4/backup
NAME          PROPERTY     VALUE     SOURCE
tank4/backup  compression  lz4       local
root@hoge:~ # cd /tank4/backup
root@hoge:/tank4/backup # ls -l sda6.tar 
-rw-r--r--+ 1 root  wheel  10927441920 Oct 20 22:44 sda6.tar
root@hoge:/tank4/backup # time tar xf sda6.tar 
3.772u 29.051s 3:11.58 17.1% 66+173k 56955+418539io 12pf+0w
root@hoge:/tank4/backup # time rm -rf test.restore
0.446u 11.615s 0:42.61 28.2% 15+171k 17198+0io 0pf+0w
root@hoge:/tank4/backup # cd
root@hoge:~ # zpool export tank4
[root@hoge ~]# uname -a
Linux hoge 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# zpool import tank4
[root@hoge ~]# zpool list tank4
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank4   368G   271G  96.7G    73%  1.00x  ONLINE  -
[root@hoge ~]# zfs list tank4/backup
NAME           USED  AVAIL  REFER  MOUNTPOINT
tank4/backup  72.8G  89.9G  72.8G  /tank4/backup
[root@hoge ~]# zfs get compression tank4/backup
NAME          PROPERTY     VALUE     SOURCE
tank4/backup  compression  lz4       local
[root@hoge ~]# cd /tank4/backup
[root@hoge backup]# ls -l sda6.tar 
-rw-r--r-- 1 root root 10927441920 Oct 20 22:44 sda6.tar
[root@hoge backup]# time tar xf sda6.tar 

real 2m15.379s
user 0m3.018s
sys 0m44.704s
[root@hoge backup]# time rm -rf test.restore

real 1m18.267s
user 0m0.318s
sys 0m13.814s
[root@hoge backup]# cd
[root@hoge ~]# zpool export tank4
すごい効果です。CentOS の tar 展開の処理時間は、Btrfs の compress-force=lzo の実験結果と同等です。それにしても、OpenIndiana の rm は抜群に速い(FreeBSDの2倍以上)ですね。

2014-04-29追記
RHEL7.0 RC と、最新の ZFS(未だに 0.6.3 が出ないので GitHub から落とした)を試してみました。こちら

2014年3月9日日曜日

CentOS 6 の root ファイルシステムに ZFS を使ってみた

ZFS on Linux 0.6.2 には zfs-dracut というパッケージが用意されており、root ファイルシステムに ZFS を利用するための仕組みが入っています。しかしながら、CentOS 6 の dracut は、バージョンが古いため、そのままでは動きませんでした。
dracut のデバッグが厄介だったのですが、どうにか動きましたので、まとめておきたいと思います。
2016-07-02追記、CentOS 7 の GRUB2 から ZFS 上の CentOS 6 を起動する方法も書きました。こちらのほうが運用し易いかと思います。

まず、前提ですが、カーネルと initramfs イメージは、GRUB が扱えるファイルシステム上に置く必要があるので、/boot だけは ext4 等にする必要があります。また、直接 ZFS 上にインストールはできないので、ext4 にインストール後に、引っ越すという手順をとる必要があります。また、将来 ZFS のバージョンアップを行う際、起動できなくならないように注意する必要がある(引越し前の ext4 の root イメージを保持しておく等の対策が必要)かと思います。また、たしか ZOL は SELinux には対応していなかったと思いますので、留意する必要があるかと思います。

以下、手順です。

(1) zfs-dracut に含まれる dracut 用のスクリプトをコピーする
# rpm -ql zfs-dracut
/lib/dracut/modules.d/90zfs
/lib/dracut/modules.d/90zfs/module-setup.sh
/lib/dracut/modules.d/90zfs/mount-zfs.sh
/lib/dracut/modules.d/90zfs/parse-zfs.sh  ※この3つをコピー
/usr/share/doc/zfs-dracut-0.6.2
/usr/share/doc/zfs-dracut-0.6.2/README.dracut.markdown
# cp -r /lib/dracut/modules.d/90zfs /usr/share/dracut/modules.d

(2) スクリプトに修正を加える
まず、関数モジュール化されたスクリプト(中を見ると関数定義だけになっており、最近の Fedora の dracut 向けの作法になってます)をコピーします。
# cd /usr/share/dracut/modules.d/90zfs
# cp module-setup.sh check
# cp module-setup.sh install
コピーしたスクリプトをちょっと加工します。差分は次の通りです。
# diff -u module-setup.sh check 
--- module-setup.sh 2013-08-23 06:39:05.000000000 +0900
+++ check 2014-02-22 21:29:28.000000000 +0900
@@ -54,3 +54,5 @@
  inst_simple "$TMP" /etc/hostid
  rm "$TMP"
 }
+
+check
# diff -u module-setup.sh install 
--- module-setup.sh 2013-08-23 06:39:05.000000000 +0900
+++ install 2014-02-22 21:30:14.000000000 +0900
@@ -31,6 +31,7 @@
  inst_rules /lib/udev/rules.d/90-zfs.rules
  inst_rules /lib/udev/rules.d/69-vdev.rules
  inst_rules /lib/udev/rules.d/60-zvol.rules
+ dracut_install /bin/awk
  dracut_install /sbin/zfs
  dracut_install /sbin/zpool
  dracut_install /lib/udev/vdev_id
@@ -54,3 +55,5 @@
  inst_simple "$TMP" /etc/hostid
  rm "$TMP"
 }
+
+install
さらに、mount-zfs.sh と parse-zfs.sh に修正を加えます。
# diff -u /lib/dracut/modules.d/90zfs /usr/share/dracut/modules.d/90zfs
Only in /usr/share/dracut/modules.d/90zfs: check
Only in /usr/share/dracut/modules.d/90zfs: install
diff -u /lib/dracut/modules.d/90zfs/mount-zfs.sh /usr/share/dracut/modules.d/90zfs/mount-zfs.sh
--- /lib/dracut/modules.d/90zfs/mount-zfs.sh 2013-08-23 06:39:05.000000000 +0900
+++ /usr/share/dracut/modules.d/90zfs/mount-zfs.sh 2014-03-08 20:43:21.086727408 +0900
@@ -2,6 +2,22 @@
 
 . /lib/dracut-lib.sh
 
+# copied from Fedora19's /usr/lib/dracut/modules.d/99base/dracut-lib.sh
+getargbool() {
+    local _b
+    unset _b
+    local _default
+    _default=$1; shift
+    _b=$(getarg "$@")
+    [ $? -ne 0 -a -z "$_b" ] && _b=$_default
+    if [ -n "$_b" ]; then
+        [ $_b = "0" ] && return 1
+        [ $_b = "no" ] && return 1
+        [ $_b = "off" ] && return 1
+    fi
+    return 0
+}
+
 ZPOOL_FORCE=""
 
 if getargbool 0 zfs_force -y zfs.force -y zfsforce ; then
diff -u /lib/dracut/modules.d/90zfs/parse-zfs.sh /usr/share/dracut/modules.d/90zfs/parse-zfs.sh
--- /lib/dracut/modules.d/90zfs/parse-zfs.sh 2013-08-23 06:39:05.000000000 +0900
+++ /usr/share/dracut/modules.d/90zfs/parse-zfs.sh 2014-02-22 21:30:39.000000000 +0900
@@ -54,5 +54,6 @@
 # modules to settle before mounting.
 if [ "${wait_for_zfs}" = "1" ]; then
  ln -s /dev/null /dev/root 2>/dev/null
- echo '[ -e /dev/zfs ]' > $hookdir/initqueue/finished/zfs.sh
+# echo '[ -e /dev/zfs ]' > $hookdir/initqueue/finished/zfs.sh
+ echo '[ -e /dev/zfs ]' > /initqueue-finished/zfs.sh
 fi

(3) 引越し先の ZFS root ファイルシステムを用意する
FreeBSD や OpenIndiana を眺めてみて、rpool/ROOT/cent6 のようなネーミングが良いだろうかとも思いましたが、やっぱり長すぎるかなとも思い、rpool/ROOT のようにしました。また、mountpoint プロパティを legacy 設定にする必要があります。
# zfs set mountpoint=legacy tank4/ROOT
# zfs get all -s local tank4/ROOT
NAME        PROPERTY              VALUE                  SOURCE
tank4/ROOT  mountpoint            legacy                 local
今回は実験ということで、既存のプール tank4 から切り出しました。もっと細かく、/var や /home を別に切り出してもいいのでしょうが、わたしの用途では、そこまでする必要を感じませんので、ROOT のみです。

(4) ルート(/)イメージのコピー
マウントしたままコピーは気が引けるので、LiveDVD 等で起動して dump コマンドを用いて、ext4 上のルート(/)イメージをバックアップします。
# dump -y -0uf /mnt_backup_disk/sdXX.dump /dev/sdXX
ext4 から起動して、ZFS 上へ展開します。
# mkdir /mnt_tank4_ROOT
# mount -t zfs tank4/ROOT /mnt_tank4_ROOT
# cd /mnt_tank4_ROOT
# restore -rf /mnt_backup_disk/sdXX.dump

(5) grub.conf に ZFS から起動するためのエントリを作成する
/boot/grub.conf に次のようにエントリーを追加します。initrd は、ext4 root 用のものとは別名(.zfsを付加)にしておきます。
title CentOS on ZFS (2.6.32-431.5.1.el6.x86_64)
        root (hd0,5)
        kernel /boot/vmlinuz-2.6.32-431.5.1.el6.x86_64 ro root=ZFS=tank4/ROOT rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=jp106 rd_NO_LVM rd_NO_DM elevator=deadline
        initrd /boot/initramfs-2.6.32-431.5.1.el6.x86_64.img.zfs

(6) fstab を書き換える
ZFS root 上の fstab の / エントリーを次のように書き換えます。
#UUID=xxxxxxxx-yyyy-zzzz-uuuu-vvvvvvvvvvvv /  ext4  defaults  1 1
tank4/ROOT                                 /  zfs   defaults  1 0

(7) ZFS root 用の initramfs を作成する
# mount -t zfs tank4/ROOT /mnt_tank4_ROOT
# mount -t devtmpfs devtmpfs /mnt_tank4_ROOT/dev
# mount -t devpts devpts /mnt_tank4_ROOT/dev/pts
# mount -t sysfs sysfs /mnt_tank4_ROOT/sys
# mount -t proc proc /mnt_tank4_ROOT/proc
# mount --bind /boot /mnt_tank4_ROOT/boot  ※ここ注意、ZFS root 上の /boot に作っておいてコピーでもOKですが
# chroot /mnt_tank4_ROOT /bin/bash
# dracut -f /boot/initramfs-2.6.32-431.5.1.el6.x86_64.img.zfs 2.6.32-431.5.1.el6.x86_64

以上です。

わたしの実験用マシン(ThinkPad T510)の様子を、参考に示します。
[root@hoge ~]# uname -a
Linux hoge 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# cat /proc/cmdline 
ro root=ZFS=tank4/ROOT rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=jp106 rd_NO_LVM rd_NO_DM elevator=deadline
[root@hoge ~]# df
Filesystem     1K-blocks      Used Available Use% Mounted on
tank4/ROOT     121070464  15237632 105832832  13% /
tmpfs            3959608        80   3959528   1% /dev/shm
tank4          119538944  13706112 105832832  12% /tank4
tank4/backup   148460288  42627456 105832832  29% /tank4/backup
tank4/backup2  108885632   3052800 105832832   3% /tank4/backup2
tank4/backup3  291054080 185221248 105832832  64% /tank4/backup3
[root@hoge ~]# zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
tank4           261G   101G  13.1G  /tank4
tank4/ROOT     14.5G   101G  14.5G  legacy
tank4/backup   40.7G   101G  40.7G  /tank4/backup
tank4/backup2  2.91G   101G  2.91G  /tank4/backup2
tank4/backup3   177G   101G   177G  /tank4/backup3
tank4/swap     1.03G   102G    80K  -
tank4/test      136K   101G   136K  legacy
tank4/zvol32   12.5G   101G  12.5G  -
[root@hoge ~]# zpool status
  pool: tank4
 state: ONLINE
  scan: scrub repaired 0 in 1h21m with 0 errors on Sun Mar  2 18:24:46 2014
config:

 NAME                                                        STATE     READ WRITE CKSUM
 tank4                                                       ONLINE       0     0     0
   mirror-0                                                  ONLINE       0     0     0
     ata-HITACHI_HTS725050A9A364_xxxxxxxxxxxxxxxxxxxx-part1  ONLINE       0     0     0
     ata-HGST_HTS721010A9E630_yyyyyyyyyyyyyy-part1           ONLINE       0     0     0

errors: No known data errors
[root@hoge ~]# zfs get all tank4/ROOT
NAME        PROPERTY              VALUE                  SOURCE
tank4/ROOT  type                  filesystem             -
tank4/ROOT  creation              Sat Feb 22 21:58 2014  -
tank4/ROOT  used                  14.5G                  -
tank4/ROOT  available             101G                   -
tank4/ROOT  referenced            14.5G                  -
tank4/ROOT  compressratio         1.00x                  -
tank4/ROOT  mounted               yes                    -
tank4/ROOT  quota                 none                   default
tank4/ROOT  reservation           none                   default
tank4/ROOT  recordsize            128K                   default
tank4/ROOT  mountpoint            legacy                 local
tank4/ROOT  sharenfs              off                    default
tank4/ROOT  checksum              on                     default
tank4/ROOT  compression           off                    default
tank4/ROOT  atime                 off                    inherited from tank4
tank4/ROOT  devices               on                     default
tank4/ROOT  exec                  on                     default
tank4/ROOT  setuid                on                     default
tank4/ROOT  readonly              off                    default
tank4/ROOT  zoned                 off                    default
tank4/ROOT  snapdir               hidden                 default
tank4/ROOT  aclinherit            restricted             default
tank4/ROOT  canmount              on                     default
tank4/ROOT  xattr                 on                     default
tank4/ROOT  copies                1                      default
tank4/ROOT  version               5                      -
tank4/ROOT  utf8only              off                    -
tank4/ROOT  normalization         none                   -
tank4/ROOT  casesensitivity       sensitive              -
tank4/ROOT  vscan                 off                    default
tank4/ROOT  nbmand                off                    default
tank4/ROOT  sharesmb              off                    default
tank4/ROOT  refquota              none                   default
tank4/ROOT  refreservation        none                   default
tank4/ROOT  primarycache          all                    default
tank4/ROOT  secondarycache        all                    default
tank4/ROOT  usedbysnapshots       0                      -
tank4/ROOT  usedbydataset         14.5G                  -
tank4/ROOT  usedbychildren        0                      -
tank4/ROOT  usedbyrefreservation  0                      -
tank4/ROOT  logbias               latency                default
tank4/ROOT  dedup                 off                    default
tank4/ROOT  mlslabel              none                   default
tank4/ROOT  sync                  standard               default
tank4/ROOT  refcompressratio      1.00x                  -
tank4/ROOT  written               14.5G                  -
tank4/ROOT  snapdev               hidden                 default
ここまで、実験的に約2週間ほど動かしましたが、安定しています。scrub をかけるとちょっと重いですが、実サーバで使えないこともないかなと思いました。ただ、ZFS 自体のアップデートだけが難点です。0.6.3 が出るのも間近みたいですし、そのあとも着々と開発が計画されているようです。

2014年2月13日木曜日

ramdisk(/dev/ram0)を使ってカーネルビルド時間を短縮

CentOS 6 のカーネルを若干カスタマイズして、再ビルドして使っている環境があるのですが、ビルド時間を多少短縮したいのと、SSD の消耗を軽減したく、ramdisk を使ってみました。

以下、自分向けのメモですが、どなたかの参考まで。

まず、ビルドに利用しているマシンは、メモリ 16G 積んでます。
カーネルをビルドするには、だいたい 10G は空きディスクが必要なので、ramdisk のサイズを 10G にするため、grub.conf にブートパラメータを追加します。
    ... ramdisk_size=10240000
再起動したら、ramdisk にメモリを割り付けてしまうため、ゼロ埋め処理します。
# shred -z -n 0 /dev/ram0
これは、dd if=/dev/zero of=/dev/ram0 bs=1M としても、いいですが。。

あとは、mkfs してマウントします。
# mkfs -t ext4 /dev/ram0
# mkdir /mnt_ram0
# mount /dev/ram0 /mnt_ram0
そんで、~/rpmbuild の内容を ram0 へコピーします。
# cd ~/rpmbuild
# tar cf - . | (cd /mnt_ram0 ; tar xf -)
最後に、ram0 を ~/rpmbuild へ再マウントします。
# umount /mnt_ram0
# mount /dev/ram0 ~/rpmbuild
これで、カーネル再ビルドの前準備完了です。

実際、やってみたところ、わたしの環境では、ビルド時間が2分程度(全体の処理時間の11%)短縮できました。

ちなみに、最初は zram を使おうとしたのですが、再ビルドしたいのは 32bit 版カーネルであり、ビルド環境も 32bit 版であるため、メモリ限界(ちゃんと調べてないですが、おそらく lowmem の限界)で、うまく行きませんでした。ramdisk のほうは、highmem を使えるようで、問題ありませんでした。

16G メモリって、なかなか使いこなせてない(余りがち)ですが、ちょっとばかり有効活用できたような気もしました。

2014-02-15追記
最初に zram を使おうと思った流れで、ramdisk + ext4 を使いましたが、他に tmpfs もあるので、そちらも試してみました。
CentOS 6 では、デフォルトで /dev/shm に tmpfs がマウントされますが、サイズが少し不足するので拡張します。あと、カーネルビルドの性質上、多数のファイルを作成するので、inode 数も拡張します。
# mount -o remount,size=10240M,nr_inodes=300000 /dev/shm
inode 数も拡張しないと、ビルドが失敗します。このとき、容量不足と勘違いしそうなメッセージ(No space left on device)が出て、紛らわしいです。

あとは、次のように bind マウントして利用しました。
# mkdir /dev/shm/rpmbuild
# cd ~/rpmbuild
# tar cf - . | (cd /dev/shm/rpmbuild ; tar xf -)
# mount --bind /dev/shm/rpmbuild ~/rpmbuild
ビルド時間は、ramdisk を利用した場合と変わりませんでしたし、tmpfs を使うほうが手軽かと思います。マシンを再起動しなくても、メモリ解放できますし。
ただ、メモリの空き状況によっては、tmpfs の中身がスワップアウトされることがあるので、その点だけ頭の片隅に置いておいたほうがよいかと。

2014-08-30追記
その後、月1回程度(CentOS 6 の errata カーネルが出る度)のペースで、tmpfs を使う方法を使ってカーネルリビルド(ちなみに HZ=250 設定と nonpae 化)していますが、ビルド時間短縮と SSD 負担軽減に役立っていると思います。先日、うっかり、tmpfs を使わずにビルドしたところ、SSD に負荷がかかり、SSD を見失った(高熱のため?)こともあり、tmpfs 役立つなあ と思いました。

2014年2月2日日曜日

CentOS 5 + UEKr2 で Btrfs raid1

CentOS 5 + UEKr2 で ZFS on Linux を使い始めて3ヶ月、安定して使えています。
ただ、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 は、構成デバイスのうちの1つだけ (上記の例なら sdb2 または sdc2) を指定すれば mount できるという特徴があります。おもしろいアイデアだと思いますが、md に慣れているわたしには、操作対象が定まらずしっくりこない感じがしました。まあ、慣れの問題かとは思いますが。

ここまでは、いたって簡単です。しかし、起動時に自動マウントしようとしたら、うまく行きませんでした。
UUID=ae4ac311-4ef1-478a-a4eb-15bfa4beedc4  /mnt_hoge  btrfs  defaults,compress-force=lzo  1 1
ext4 等と同じ感覚で 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 の3パターン)。
[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 の性能を測ってみました。下記参照。
3つの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 0
OracleLinux 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追記
手持ちマシンのうちの1台で、ルートVOL(/)を Btrfs RAID1(Plextor SSD M6M 128G x 2)にして CentOS7 を使い始めました。マルチブート環境ですが、Btrfs RAID1 に GRUB2 をインストールしても平気なようです。インストール時は、ext4 で1パーティションにインストールして、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 出力が素直になっていた件
人気ブログランキングへ にほんブログ村 IT技術ブログへ