2015年1月25日日曜日

RHEL7 / CentOS7 で ext4 を使ってみる(16T 越えの確認)

RHEL7 / CentOS7 では、デフォルトのファイルシステムが XFS になっていて、しきりと推奨/宣伝されているように感じますが、個人的には、16T を越える領域を扱うのでもなければ、ext4 を利用してもよいのではと思います。慣れている&(自分の利用範囲で)XFS より実績があるので。
特に、OS 領域(大抵の場合 20G〜50G 程度で済むのではと思う)は ext4 でもいいのではと思います。16T を越えるデータ領域に XFS を利用するので、OS 領域も全て XFS で統一するという考え方もあろうかと思いますが。。。

さて、最近は ext4 も拡張されており、16T 越えも可能なはずなので、試してみました。ただし、16T ものディスクを所有していませんので、ZFS on Linux の機能(sparse ZVOL)を利用しました。
[root@hoge ~]# zfs create -s -V 200T tankS/ext4_test    ※ZFS のチカラを借りて、200T の領域を作成
[root@hoge ~]# mkfs -t ext4 /dev/tankS/ext4_test        ※ext4 ファイルシステム作成
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks:  8193142done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=2 blocks, Stripe width=2 blocks
3355443200 inodes, 53687091200 blocks
2684354560 blocks (5.00%) reserved for the super user
First data block=0
1638400 block groups
32768 blocks per group, 32768 fragments per group
2048 inodes per group
Superblock backups stored on blocks: 
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
 102400000, 214990848, 512000000, 550731776, 644972544, 1934917632, 
 2560000000, 3855122432, 5804752896, 12800000000, 17414258688, 
 26985857024, 52242776064

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

[root@hoge ~]# mount /dev/tankS/ext4_test /mnt_temp
[root@hoge ~]# df -Th /mnt_temp
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/zd0       ext4  200T   20K  190T   1% /mnt_temp
[root@hoge ~]# dd if=/dev/zero of=/mnt_temp/test.dd bs=1M count=500 conv=fsync
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 28.1099 s, 18.7 MB/s
[root@hoge ~]# df -Th /mnt_temp
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/zd0       ext4  200T  501M  190T   1% /mnt_temp
200T ほど試してみましたが、ちゃんとマウントして利用できました。なお、下地になっている ZFS プールのディスクが USB 2.0 接続になっており、dd の書き込みが遅いのはそのせいです。これなら難無く使えそうに思われるかもしれませんが、上記操作例の中で、mkfs が5分ほどかかっています。USB 2.0 の影響もあるだろうと思いますが、XFS ならば、もっと速いだろうと思います。
それから、てっきり ext4 の 16T 越え機能拡張は、ブロックサイズを 4K よりさらに大きくすることで達成されているものと勘違い/誤認識していましたが、mkfs の出力にもあるとおり、ブロックサイズは 4K のままのようです。ただし、作成された ext4 には、新しい feature flag である 64bit が付与されます。
[root@hoge ~]# tune2fs -l /dev/tankS/ext4_test
...
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
...
この 64bit フラグは、デフォルトになっており、16T 未満の場合でも付与されてしまうので、RHEL6 / CentOS6 でもマウントしたい領域を作る場合は、注意必要と思われます。
次は、/etc/mke2fs.conf から抜粋です。
...
[fs_types]
 ext3 = {
  features = has_journal
 }
 ext4 = {
  features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize,64bit
  inode_size = 256
 }
...
もし、64bit フラグを付与したくないならば、次のようにすれば良いです。
[root@hoge ~]# mkfs.ext4 -O ^64bit /dev/sdXXX

ただし、この 64bit フラグは、後から追加することはできないようです。
[root@hoge ~]# tune2fs -O 64bit /dev/tankS/ext4_test
tune2fs 1.42.9 (28-Dec-2013)
Setting filesystem feature '64bit' not supported.
64bit フラグなしで 15T から 17T への resize2fs も試してみましたが、NG です。
[root@hoge ~]# zfs get volsize tankS/ext4_test
NAME             PROPERTY  VALUE    SOURCE
tankS/ext4_test  volsize   17T      local    ※あとから zfs set volsize で 15T から 17T にサイズを拡張
[root@hoge ~]# df -Th /mnt_temp
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/zd0       ext4   15T  6.3M   15T   1% /mnt_temp    ※15T の段階で mkfs して mount しておいた
[root@hoge ~]# resize2fs /dev/tankS/ext4_test
resize2fs 1.42.9 (28-Dec-2013)
resize2fs: New size too large to be expressed in 32 bits    ※NG です。予想通りですが

2015-01-28追記
もしも、許される&自分で面倒みることができるならば ZFS が最強 (End-to-Endチェックサム+RAID機能によるデータ破損検出と自動修復・・・抜群の安心感が得られるし実際に助かったことがあるスナップショット・・・こまめに採ることでファイルサーバを「Time Capsule」化できるZVOL・・・これ意外と重宝する透過圧縮・・・ソース置き場や大容量テキスト解析に便利重複排除・・・効果発揮できる局面が限定されますが) だろうと思っていますが、商用利用のサーバだと難しい(ディストリビュータや商用サポートサービスなどの後ろ盾がないと許されない)かと思います。その場合、現在のところは、やっぱり無難な ext4 が、良いんじゃないのと思うわけです。


2015-01-28追記
XFS よりも ext4 のほうがネット上の情報(ノウハウ)も多いに違いないと思いましたが、ためしに Google 検索で、キーワード「Linux XFS」と「Linux ext4」を試してみると、やはり ext4 のほうが2倍程度のヒット数となりました。参考メモ。

2015年1月16日金曜日

CentOS7 で NIC と ethX の対応を固定化する

CentOS 7 では、NIC 交換 (オンボードの場合はマザーボード交換も含む) した場合でも、インターフェース名が変化しないようにする仕組みがデフォルトで有効になっていますが、ネーミングが旧来の ethX とは異なり、enXXXX(例えばわたしの ThinkPad T510 では enp0s25)となります。
慣れの問題なので、そのままデフォルトで使うのがよかろうとは思いますが、もしどうしても旧来の ethX にしたい場合は、以下のような方法(1例です)があります。

vi などで、次のような記述を含む /etc/udev/rules.d/10-local.rules を作成する。
KERNEL=="en*", KERNELS=="0000:00:19.0", NAME:="eth0"
ここで、KERNELS に指定する PCI アドレスは、次のようにして確認できます。
# ethtool -i enp0s25
driver: e1000e
version: 2.3.2-k
firmware-version: 0.12-1
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
マシンを再起動すると、dmesg に次のような出力が出て、enp0s25 が eth0 にリネームされたことが読み取れます。
# dmesg
...
[    4.173829] systemd-udevd[435]: renamed network interface enp0s25 to eth0
...
上記に加えて、/etc/sysconfig/network-scripts/ifcfg-eth0 には HWADDR を指定しないでおけば、NIC 交換やマザーボード交換をする事態になっても、設定ファイルの修正を行わなくても済むはずです。
#
# network-scripts/ifcfg-eth0
#
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
#BOOTPROTO=static
#IPADDR=X.Y.Z.111
#NETMASK=255.255.255.0
#GATEWAY=X.Y.Z.254
### HWADDR=xx:yy:zz:uu:vv:ww    ※NIC 交換で MAC アドレスが変わっても影響受けないようにコメントアウト
USERCTL=no
NM_CONTROLLED=no
#DHCP_HOSTNAME=hoge
#ETHTOOL_OPTS="autoneg off speed 100 duplex full"
#
#DNS1=X.Y.Z.1
#DNS2=
#DOMAIN=
あと、ifcfg-enp0s25 のような、リネーム前の設定ファイルを消しておくこともお忘れなく。

2015-01-18追記
RHEL7 でも同様です。いわずもがなですが。

人気ブログランキングへ にほんブログ村 IT技術ブログへ