特に、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_temp200T ほど試してみましたが、ちゃんとマウントして利用できました。なお、下地になっている ZFS プールのディスクが USB 2.0 接続になっており、dd の書き込みが遅いのはそのせいです。これなら難無く使えそうに思われるかもしれませんが、上記操作例の中で、mkfs が５分ほどかかっています。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 のほうが２倍程度のヒット数となりました。参考メモ。
0 件のコメント:
コメントを投稿