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 の初期確認
人気ブログランキングへ にほんブログ村 IT技術ブログへ