CentOS 6.5 のトピックス

CentOS 6.5 で新たに追加された機能等の、自分用メモです。
なんと言っても、個人的には md の TRIM サポートが追加されたことがありがたいです。

https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/6.5_Release_Notes/bh-storage.html
～抜粋～
mdadm での TRIM サポート
mdadm ツールは、RAID0、RAID1、RAID10、RAID5 向けに TRIM コマンドをサポートします。
～～～

SSD を md で束ねたい方に朗報ではないかと思います。md RAID0 (SSD 3台利用) の上に ext4 を作成して試してみましたが、fstrim 出来るようになってました！

＜その他に目に留まったもの＞
・makedumpfile に LZO と Snappy サポートが追加。ダンプ時間短縮に有効です。

2014-05-11追記
md RAID0 以外でも TRIM が動くのか、RAID1、RAID10、RAID5 も試してみましたが、わたしの環境では RAID1 + ext4 は fstrim 出来ましたが、RAID10 と RAID5 は NG でした。使った SSD は、Plextor の M6M です。hdparm によると、M6M は、RZAT/DRAT の両方が非対応になっているようなので、もしかしたらそこらが関係するのだろうかと思ってます。パッチを読めという話でしょうが、また今度。。

2014-05-12追記
カーネル 2.6.32-431.17.1.el6 の changelog を確認してみたら、RAID5 については、

2013-11-10 12:00:00
Rafael Aquini  [2.6.32-431.el6]:
- [md] Disabling of TRIM on RAID5 for RHEL6.5 was too aggressive (Jes Sorensen) [1028426]
...
2013-10-21 12:00:00
Rafael Aquini  [2.6.32-425.el6]:
...
- [md] Disable TRIM on RAID5 for RHEL 6.5 (Jes Sorensen) [837097]

6.5 の最終段階で、disable にされたようです。何らか、うまく行かないパターンがあったのでしょう。
あと、RAID10 についてですが、先日、実験する際、起動するカーネルを間違えていたようで、オラクル UEKr2 を使っていたせいのようです。あらためて、2.6.32-431.17.1.el6 で再度実験を行ったところ、Plextor M6M の md RAID10 + ext4 は OK でした（fstrim 動きました）。

ファイルをスパース（sparse）化する方法

主に、Linux のクラッシュダンプファイル、または、プロセスのコアファイルを、誰かから送付してもらった場合、本来スパースファイルであるものが、送付方法によっては非スパース化してしまって、ディスクを浪費してしまう場合があります。
そんな局面で、スパースファイルに戻す方法です。

# dd if=/dev/zero of=test.dd bs=4096 count=1000    ※実験のためオールゼロファイル作成
1000+0 records in
1000+0 records out
4096000 bytes (4.1 MB) copied, 0.092697 seconds, 44.2 MB/s

# du -hs test.dd 
4.0M    test.dd

# cp -p --sparse=always test.dd test.dd.sparsed

# du -hs test.dd.sparsed    ※確認
0       test.dd.sparsed

書くまでもないですが、圧縮形式の vmcore には効果が無いですから、上記の操作でディスク節約を試みる前に、file コマンドで形式を確認したほうがいいです。

# file vmcore 
vmcore: data    ※これだったらダメ

なお、逆に誰かにダンプやコアファイルを送付する場合は、次のように tar の S オプションをつけてセーブすると親切です。親切かどうかチェック（相手のレベルをチェック）してたりします。(^ー^;＞

# tar zcfS vmcore.tgz ./127.0.0.1-2010-08-31-23:27:08/vmcore

./127.0.0.1-2010-08-31-23:27:08/ の部分も小さな親切になります。

2011-11-27追記
カーネルのクラッシュダンプや core 以外にも、KVM などの仮想マシンで使う仮想ディスクファイルもスパースなので、上記方法が役に立つ (応用できる) 場合があるかと思います。
次のURLの方のように、仮想マシン上からゼロ書き込み後に cp --sparse=always でスパース化処理すれば、理論上は仮想ディスクファイルが縮小できる場合があるはず。
http://www.syuhitu.org/other/skipspace/skipspace.html

CentOS 5.5 において ext4 に kdump 出力する

CentOS 5.5 では、ext4 が使えるので、自分の管理している小規模サーバでは、全て ext4 にしてしまった。CentOS 5.5 のインストーラーでは、/ を ext4 にしてインストールしようとすると蹴られるのだが、予め、インストール CD からレスキューモードを起動して、ファイルシステムを作成してしまうことで、うまくインストールできた。本題ではないが、ext4 のファイルシステム作成手順は、次のとおり。

# mke2fs -j /dev/sda3          ※まずは、ext3 を作る

# tune4fs -O extent /dev/sda3  ※エクステントフラグを付加（ext4化する）する。これがキモ
      ※CentOS 5.5 の場合、tune4fs なので注意

# tune4fs -O flex_bg     /dev/sda3  ※その他のオプションを設定
# tune4fs -O huge_file   /dev/sda3  ※  そのうち、もう少し詳細を書こう
# tune4fs -O uninit_bg   /dev/sda3  ※
# tune4fs -O dir_nlink   /dev/sda3  ※
# tune4fs -O extra_isize /dev/sda3  ※

さて、kdump の領域に ext4 を使うには、ext3 の場合と同様に記述するのですが、次のように extra_bins の指定も必要です。これをやらないと、セカンドカーネルでダンプ採取領域をマウントする前の fsck が出来ず（fsck.ext4 が見つからないといわれる）、ダンプが失敗します。

extra_bins /sbin/fsck.ext4
ext4 LABEL=/
path /var/crash
core_collector makedumpfile -c -d 1

なお、ext3 で kdump 専用領域を作ったほうがいいのかもしれませんが、kdump のために遊ばせておくというのもと思うため、/ １個にしています。/var も分割していません。もし重要度の高い業務用サーバなら /var を独立させて、ログとダンプ置き場専用とするのが一番無難だろうと思います。

2010-12-18追記
ext4 を使う前に、こちらも確認を。

2011-03-27追記
ext4 のファイルシステム作成は、mkfs.ext4 で行えば、最初に書いたような tune4fs でのオプション設定は不要でした。

2011-08-02追記
今ごろ気がつきましたが、既に 5.6 で kexec-tools に ext4 サポートが追加されていました。
http://rhn.redhat.com/errata/RHEA-2011-0146.html
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=667966
上のような小細工をするよりも、kexec-tools をアップデートしましょう。

kdump に lzop を使う方法

kdump にはダンプファイルを圧縮する設定があり、普通は core_collector ディレクティブに makedumpfile -c を指定するという方法をとる。ただ、圧縮処理には結構な時間がかかり、これを短縮する方法はないかと考えてみた。

makedumpfile -c を指定した場合の initrd内のinit には、次のような記述が埋め込まれる。

mount -t ext3 $DUMPDEV /mnt
if [ $? == 0 ]
then
  mkdir -p /mnt///127.0.0.1-$DATE
  VMCORE=/mnt///127.0.0.1-$DATE/vmcore
  export VMCORE
  makedumpfile -c /proc/vmcore $VMCORE-incomplete >/dev/null

つまるところ core_collector に指定するフィルタプログラムは cp のシンタックスを満たせば良いようだ。 数ある圧縮プログラムの中で、高速であることを特徴とするものに lzop というプログラムがあり、これを使いたい。ただ、コマンドラインオプションを細工しても、cp のシンタックスを満たすようにはできないので、一皮かぶせる。

#! /sbin/busybox msh
/usr/bin/lzop -o $2 $1

こいつを、/etc/kdump.conf に次のような形で指定する。

ext3 LABEL=/1
path /var/crash
extra_bins /usr/bin/lzop /usr/bin/lzop.copy
core_collector lzop.copy

そうすると、initrd 内に lzop 関連のファイルが全部入る。

# zcat /boot/initrd-2.6.18-194.el5kdump.img | cpio -tv | grep lzo
-rwxr-xr-x   1 root     root       125672 Aug 31 23:19 usr/lib64/liblzo2.so.2
-rwxr-xr-x   1 root     root           44 Aug 31 23:19 usr/bin/lzop.copy
-rwxr-xr-x   1 root     root        67288 Aug 31 23:19 usr/bin/lzop
17070 blocks

initrd内のinitは次のように展開される。

mount -t ext3 $DUMPDEV /mnt
if [ $? == 0 ]
then
  mkdir -p /mnt//var/crash/127.0.0.1-$DATE
  VMCORE=/mnt//var/crash/127.0.0.1-$DATE/vmcore
  export VMCORE
  lzop.copy /proc/vmcore $VMCORE-incomplete >/dev/null

これでうまいこと、lzop 圧縮でダンプファイルが生成できました。

# pwd
/var/crash/127.0.0.1-2010-08-31-23:27:08
# file vmcore 
vmcore: lzop compressed data - version 1.020, LZO1X-1, os: Unix

gzip や bzip2 でも、同様にできるものと思いますが、速度の面から考えて、有用なのは lzop だけなのではと思います。
なお、lzop は RHEL6 Beta2 には含まれてましたが、RHEL5 には含まれていませんので、rpmfind などから拾ってくる必要があります。

2010-12-05追記
lzop で採取されたダンプの参照方法と、lzop を用いた場合の効果を書いていなかったので、まとめたいと思います。
まず、lzop で採取されたダンプの解凍方法とダンプ参照方法。

# ls -l vmcore
-r-------- 1 root root 922628641 Dec  5 11:50 vmcore.lzo

# file vmcore 
vmcore: lzop compressed data - version 1.020, LZO1X-1, os: Unix

# mv vmcore vmcore.lzo

# lzop -d vmcore.lzo 

# ls -l vmcore
-r-------- 1 root root 4122392804 Dec  5 11:50 vmcore

# crash /boot/System.map-2.6.18-194.el5 /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux vmcore

  SYSTEM MAP: /boot/System.map-2.6.18-194.el5                          
DEBUG KERNEL: /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux (2.6.18-194.el5)
    DUMPFILE: vmcore
        CPUS: 2
        DATE: Sun Dec  5 11:49:50 2010
      UPTIME: 00:43:27
LOAD AVERAGE: 2.03, 1.71, 1.33
       TASKS: 144
    NODENAME: my39
     RELEASE: 2.6.18-194.el5
     VERSION: #1 SMP Fri Apr 2 14:58:14 EDT 2010
     MACHINE: x86_64  (1196 Mhz)
      MEMORY: 3.9 GB
       PANIC: "SysRq : Trigger a crashdump"
         PID: 7544
     COMMAND: "bash"
        TASK: ffff81011dbf7040  [THREAD_INFO: ffff81010fdf2000]
         CPU: 1
       STATE: TASK_RUNNING (SYSRQ)

crash> 

次に同じマシンで makedumpfile -c -d 1 で採取したダンプの情報です。こちらの場合は、圧縮したまま crash に渡すことができます。

# ls -l vmcore 
-rw------- 1 root root 848124021 Dec  5 12:03 vmcore

# file vmcore 
vmcore: data

# crash /boot/System.map-2.6.18-194.el5 /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux vmcore

  SYSTEM MAP: /boot/System.map-2.6.18-194.el5                          
DEBUG KERNEL: /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux (2.6.18-194.el5)
    DUMPFILE: vmcore  [PARTIAL DUMP]
        CPUS: 2
        DATE: Sun Dec  5 11:56:53 2010
      UPTIME: 00:04:52
LOAD AVERAGE: 0.23, 0.29, 0.13
       TASKS: 144
    NODENAME: my39
     RELEASE: 2.6.18-194.el5
     VERSION: #1 SMP Fri Apr 2 14:58:14 EDT 2010
     MACHINE: x86_64  (1197 Mhz)
      MEMORY: 3.9 GB
       PANIC: "SysRq : Trigger a crashdump"
         PID: 6310
     COMMAND: "bash"
        TASK: ffff8101371d07e0  [THREAD_INFO: ffff81013ad80000]
         CPU: 1
       STATE: TASK_RUNNING (SYSRQ)

crash> help -n | grep dump_level
          dump_level: 1 (0x1) (DUMP_EXCLUDE_ZERO)

lzop で採取した場合と、makedumpfile -c -d 1 で採取した場合のデータを整理すると、次のようになります。

■ lzop で採取した場合
ダンプ採取所要時間：1分22秒（kdump_post を使ってタイムスタンプを記録して測定）
ダンプファイルサイズ：922628641

■ makedumpfile -c -d 1 で採取した場合
ダンプ採取所要時間：6分34秒（kdump_post を使ってタイムスタンプを記録して測定）
ダンプファイルサイズ：848124021

このように、ダンプファイルサイズが少し大きくなる程度で、ダンプ採取時間が大幅に短縮（＝ダウンタイムが大幅に短縮）でき、LZO の威力（高速圧縮性能）が発揮された結果となりました。 最後になりましたが、実験は、ThinkPad X300 メモリ4GB ＋ CentOS 5.5 x86_64 で行いました。環境情報を示します。

# uversion 
CentOS release 5.5                      647818J

BIOS version  : 7TET36WW (1.10 )  05/11/2009
System serial : xxxxxxx

CPU model  : Intel(R) Core(TM)2 Duo CPU     L7100  @ 1.20GHz
Processors : 2  (1 sockets, 2 cores per CPU, HT: not supported or disabled)

Memory : 3780 MB

Linux : 2.6.18-194.el5  x86_64  (my39)

この環境で、システム起動直後にテストデータ（Webサーバを想定してテキストデータ）でキャッシュを満タンにした状態でダンプ採取して、比較しました。

2011-06-19追記
dumpコマンドのLZO圧縮オプション
よければ、こちらも、参照ください。

2011-06-26追記
EPEL というのがあることを知り、確かめてみたら、lzop も入ってました。
http://download.fedora.redhat.com/pub/epel/5/

2012-11-25追記
64bit版の CentOS 6 または RHEL6 であれば、lzop が収録されています。

2013-12-07追記
CentOS 6.5 で、makedumpfile (kexec-tools パッケージに収録) に -l オプション (LZO 圧縮サポート) が追加されましたので、上のような小細工は必要なくなりました。同時に Snappy のサポート (-p オプション) も追加されています。どちらが効果的かは、サーバの使い方によるかと思います。