アプリケーション

【Linux】Amazon Lightsail にインストールした CentOS 7 の inode 上限を変更する

@rabirgoです。

以下のポストの続きです。

【Linux】Lightsail にインストールした CentOS 7 に fstransform をインストールする@rabirgoです。 趣味用サーバの移行をしようとしてて、fstransform をインストールしようとしてハマったので記録して...

結局 CentOS 7 のファイルシステムは xfs で、inode の上限変更は可能みたいなので変更します。

inode(数)とは

inode 数は、ざっくりいうと作成できるディレクトリとファイル数の上限と思ってもらえばいいのかなと思います。

長く使って、いろんなバージョンのソフトウェアをインストールしたりして、ゴミ掃除しないと枯渇することがあります。

枯渇するとどうなるかというと、容量的には空いていても、Disk full というエラーが出てしまいます。

$ touch /tmp/tmpfile
touch: cannot touch `/tmp/tmpfile': デバイスに空き領域がありません

$ df -h # /dev/vda3 にはディスクの空きはある
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda3       195G   89G   97G  48% /
tmpfs           939M     0  939M   0% /dev/shm
/dev/vda1       239M   79M  148M  35% /boot

$ df -i # でも inode が枯渇している(100% 使用している)
Filesystem       Inodes    IUsed  IFree IUse% Mounted on
/dev/vda3      12967936 12967936      0  100% /
tmpfs            240276        1 240275    1% /dev/shm
/dev/vda1         64000       50  63950    1% /boot

調べた結果、CentOS 6 で採用されている ext4 というファイルシステムでは、後からの上限値変更ができないようです。

ようこそ ArchWiki へ。ArchWiki は Arch Linux のウェブドキュメントです。

ファイルシステムを作成した後に bytes-per-inode レシオや inode の数を変更することはできない

ファイルを削除するしかないのですが、どのファイルを削除すれば良いか分からなくなったので乗り換えることにしました。

【AWS】Amazon Lightsail を契約してみた(プラン)@rabirgoです。 趣味で使ってるさくら VPS のノード数が限界に来てて、どうしていいかわからなくなったのでサーバ移行するこ...

デフォルトの inode上限を確認

まず、Amazon Lightsail にインストールした CentOS 7.6(生成したインスタンス、という呼び名が正しい?)の状況を見てみます。

sudo xfs _info / | grep imaxpct (Lightsail CentOS 7.6 初期値)

$ sudo xfs_info / | grep imaxpct
data     =                       bsize=4096   blocks=10485499, imaxpct=25

df -i (Lightsail CentOS 7.6 初期値)

$ df -i
ファイルシス    Iノード I使用    I残り I使用% マウント位置
/dev/xvda1     20970992 30076 20940916     1% /

inode の上限は 20,970,992 でした。

これは移行前の CentOS 6.6 での 12,967,936 よりは多いですが、1.6倍程度。
ちょっと心許ない気がするので、2倍程度になるよう増やしたいと思います。

df -i (さくら VPS CentOS 6.6, 2014年12月より運用開始)

$ df -i
Filesystem       Inodes    IUsed  IFree IUse% Mounted on
/dev/vda3      12967936 12967936      0  100% /

inode 上限変更(xfs_growfs)

xfs_growfs というコマンドを使うようです。

xfs_growfs expands an existing XFS filesystem (see xfs(5)). The mount-point argument is the pathname of the directory where the filesystem is mounted. The ...

sudo xfs_growfs -m 40 /dev/xvda1

40% に変更してみました。

$ sudo xfs_growfs -m 40 /dev/xvda1
meta-data=/dev/xvda1             isize=512    agcount=21, agsize=524224 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=10485499, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
inode max percent changed from 25 to 40

sudo xfs_info / | grep imaxpct

変更できたことを確認します。

$ sudo xfs_info / | grep imaxpct
data     =                       bsize=4096   blocks=10485499, imaxpct=40
$ df -i
ファイルシス    Iノード I使用    I残り I使用% マウント位置
/dev/xvda1     33553592 30076 33523516     1% /

imaxpct が更新されたことと、inode 上限が増えたことが確認できました。
とりあえずこれでファイル数の心配はないかなと思います。

さいごに

通常の運用では inode の枯渇は起きないと思いますが、いろいろいじったりデータを取ったりしてるとファイル数が増えてしまうんですよね。。

ちなみに iMac の場合、以下のようになってます。

$ df -i
Filesystem                                                                                          512-blocks       Used Available Capacity   iused               ifree %iused  Mounted on
/dev/disk2s1                                                                                        4143187984 3241697984 870240664    79%   2943666 9223372036851832141    0%   /

4,143,187,984 なので、inode が枯渇した CentOS 6 の 12,967,936 より 320 倍程度のディレクトリ数、ファイル数に耐えられるということになるんじゃないかなと思います。(ファイルシステムが違うので同じかどうか把握できてませんが・・)

サーバ管理、慣れてないので知識が少なく時間かかりますが、知らないことを学べるので楽しいですね。

時間ができたら bot で作業効率化できるようになりたいです。

ABOUT ME
rabirgo
うさぎ年(rabbit)おとめ座(virgo)生まれの rabirgo です。 2019年よりフリーランスとして活動しています。 よかったら Twitter フォローお願いします! Follow @rabirgo

COMMENT

メールアドレスが公開されることはありません。