web-dev-qa-db-ja.com

resize2fsがパス3（iノードテーブルのスキャン）でスタックしているようです-どうすればよいですか？

Highpoint RocketRaid2320に接続された6TBRAID-5アレイを備えたArchLinux（2010、私は信じています）を実行しているマシンがあります。ドライバーがないため、RAIDコントローラーのドライバーと最新のLinuxカーネルで問題が発生しています。オープンソースであるため、システムをWindowsServerに移行しています。

問題は、6TBディスクが元々ext4パーティションのみで構成されていたことです。パーティションを可能な限り縮小し、空のスペースにNTFSパーティションを追加して、ファイルの移動を開始できるようにしました。それはうまくいきました。問題は、ext4パーティションを縮小する必要があることです再び、ファイルを移動する、再度縮小するなど。resize2fsの2回目の実行は、最初のパスよりも時間がかかります。パス3でスタックしているようです。

[root@nar-shaddaa rc.d]# resize2fs -p /dev/sdb3 863000000
resize2fs 1.41.14 (22-Dec-2010)
Resizing the filesystem on /dev/sdb3 to 863000000 (4k) blocks.
Begin pass 2 (max = 29815167)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 36670)
Scanning inode table          XXXXXXXXXXX-----------------------------

それはこのように座っていて、19時間以上の間1つのコアの100％を吸い上げています：

[root@nar-shaddaa rc.d]# ps aux | grep resize2fs
root     16277 94.1 19.8 627096 613940 pts/1   R+   Jun15 1184:37 resize2fs -p /dev/sdb3 863000000

私はもともとresize2fs -P /dev/sdb3を実行して最小パーティションサイズを取得していましたが、安全のために、最も近い100万番目のブロック（したがって8億6300万）に切り上げました。 resize2fsを開始する前に、e2fsckはファイルシステムをクリーンであると報告しました。

[root@nar-shaddaa rc.d]# e2fsck -yv /dev/sdb3
e2fsck 1.41.14 (22-Dec-2010)
x-files: clean, 286672/300400640 files, 867525660/1201576187 blocks

これがfar最初のサイズ変更にかかった時間（1時間弱）より長く続いていて、resize2fsからいかなる種類の更新も取得していないように見えるので心配ですそれでも、明らかにCPUサイクルを吸い込んでいます。私はもっ​​と長く待つのですか（もしそうなら、どれくらい待つのですか）？または、キャンセルして別のツールを使用してパーティションのサイズを縮小しますか？

linuxpartitioningfilesystemsext4
5
JonnyFunFun

私はついにそれが何であるかを理解しました。元のサイズ変更をキャンセルした後（単純なctrl + C）、e2fsck -f -y /dev/sdb3を実行して問題を修正しました。パーティションを元のサイズのままマウントできたので、データが失われることはありませんでした。次に、デバッグフラグ（resize2fs -d 14 <xxx>）を指定してresize2fsを実行すると、iノードのチャンクを再配置しようとして一定のループでスタックしていることに気付きました。

古いバージョンのe2fsprogsを使用して、ようやく動作するようになりました。 Ubuntu 9.10（Karmic Koala）をUSBスティックに置き、起動し、アレイを操作できるようにオープンソースのrr232xドライバーをインストールし、古いバージョンのe2fsprogs（resize2fs 1.41.9（22-Aug-2009）を実行しました。 、正確には）。

私はもともとresize2fs -p /dev/sdb3 863000000を試しましたが、2600万ブロックが必要だと言われました。そこで、ターゲットサイズを取得し、それに追加してresize2fs -p /dev/sdb3 1000000000を実行しました。 10分後、次のメッセージが表示されます。

/ dev/sdb3は1000000000ブロックになりました

さて、究極の質問は、なぜ新しいバージョンのe2fsprogsが、私が小さすぎるサイズを要求しているのかを教えてくれなかった/教えてくれなかったのか（そして、そもそもなぜそれが小さすぎるサイズを提供したのか）だと思います。

2
JonnyFunFun