Amazon EC2でmdadm、lvm2、XFSを組み合わせて使用しています。
これまでのところ、多数のEBSボリュームから構築されたRAID5ボリュームの実行に成功しています。 EBSボリュームが接続され、mdadmで使用されてRAID 5が作成されます。次に、LVMを使用して、結果のRAIDを単一の物理ボリュームと単一の論理ボリュームとして表示します。
以前は、新しいEBSボリュームを追加してアタッチし、次のプロセスを実行することで、ファイルシステムを拡張することができました。
mdadm --add /dev/md0 /dev/xvdi
# grow the raid... (could take a while for a large disk!)
mdadm --grow /dev/md0 --raid-devices=4
# grow the LVM physical volume
pvresize /dev/md0
# grow the LVM logical volume ... fairly certain
# -l100%PVS will make the extents use as much space
# as possible on physical disks (and hopefully won't overwrite anything)
lvresize -l100%PVS /dev/data_vg/data_lv
# resize the file system, too!
xfs_growfs /dev/data_vg/data_lv
# yay!
df -h
これを行うための私の最近の試みは、表面上はうまく機能しました。 df -ih/fhを実行すると、予想どおり、追加のテラバイトが使用可能なマウント済みファイルシステムがあることがわかります。また、使用されるiノードの総数はわずか1%です。また、pvdisplayとlvdisplayも適切なボリュームサイズを表示します。
ボリュームを増やしてから、ボリュームにデータ(約150GB)を追加することもできました。しかし、今日私はディレクトリを作成して取得しようとします
mkdir:デバイスにスペースが残っていません
利用可能なiノードがたくさんあるとされる場合、なぜこの問題が発生するのでしょうか。
ディスクをアンマウントしてxfs_checkを実行しましたが、問題は報告されません。
ありがとう!
次の方法で問題を解決できました。
umount [the mountpoint]
mount /dev/data_vg/data_lv -o inode64 [the mountpoint]
どうやら、デフォルト(32ビットiノード?)のxfsは、すべてのiノードをディスクの最初の1TB部分に格納します。これは、最初の1TBがいっぱいの場合、十分なスペース/ iノードが使用可能であるように見えても、ディスク上のスペースエラーが発生しないことを意味します。私が正しく理解していれば、inode64オプションを追加することで、ノードをディスク上のどこにでも保存できます。
出典: XFS FAQ。