☰

ext4 Ubuntu 18.04 ファイル システム エラー「構造をクリーニングする必要があります」

tag-icon • tag-icon ubuntu ext4
ext4 Ubuntu 18.04 ファイル システム エラー「構造をクリーニングする必要があります」

24TB のディスクを用意して、1 つのディレクトリに膨大な数のディレクトリとファイルを格納できるようにしたいと考えています (この戦略を変更するように言わないでください。これは、私たちにとってブラック ボックスであるソフトウェアによって使用される構造であるため、このアプローチを変更することはできません)。十分に調査したところ、ext4 ファイルシステムには 1 つのディレクトリに数十億のファイルを格納する機能がありますが、特別なフラグとパラメーターを使用して準備する必要があります。これは、調査に基づいて私が使用したものです。

sudo mke2fs -T news /dev/sdb1
sudo tune2fs -O dir_index /dev/sdb1
sudo tune2fs -O large_dir /dev/sdb1
sudo tune2fs -O dir_nlink /dev/sdb1


sudo mkdir /hdd
sudo gedit /etc/fstab

- add following to the end of the file:
/dev/sdb1    /hdd    ext4    defaults,noatime    0    0

sudo mount /hdd

構造をテストするために、単一のディレクトリにディレクトリとファイルを作成する bash スクリプトを用意しました。次のようなものです。

for ((i = 1000000; i <= 200000000; i++))
do
  sudo mkdir "/hdd/largedir/$i" -p
  sudo cp "sample-file.jpg" "/hdd/largedir/$i"
  if (( $i % 1000 == 0 ));
  then
    echo "$i created";
  fi;
done

何時間も作業した後、システムをチェックすると、次のエラーが表示されていました。

Structure needs cleaning

私のテストでは、このエラーはすべてのファイルとディレクトリに対して出力されるわけではありません。たとえば、「10000」という名前のディレクトリは作成できますが、「1000」という名前のディレクトリは作成できません。また、次のコマンドを使用してハッシュ アルゴリズムを変更しました。

sudo tune2fs -E "hash_alg=tea" /dev/sdb1

システムを再起動して再マウントしましたが、問題は依然として存在します。問題が何で、ファイルシステムでなぜこの状況が発生したのか知っている人はいますか? ext4 ファイルシステムは、このような大きな構造を持つには強度が足りないのでしょうか? 大量のファイルには ext4 ではなく xfs を使用するというページをいくつか読みました。これは本当でしょうか?

ファイル操作中に、電源が切れたり、システムクラッシュが発生したりしていないことがわかります。すべてが正常だったときにこのような動作が発生するとは予想していませんでした。

-- 詳細情報を編集しました: --

ディスクの inode 情報は次のとおりです。

Filesystem        Inodes     IUsed     IFree IUse% Mounted on
/dev/sdb1      421216256 183643803 237572453   44% /hdd

スペース情報は以下の通りです。

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        26T  3.1T   21T  13% /hdd

ファイルシステムをチェックしたところ、ext4 でした (さまざまなツールで表示)。たとえば、gparted はパーティション ファイルシステムを ext4 として表示します。機能については、上記の機能はどれも、Ubuntu 18.04 LTS ではデフォルトで有効になっていませんでした。以前のテスト中にいくつかのエラーが発生し、最終的にこれに至りました。

答え1

このコマンドではsudo mke2fs -T news /dev/sdb1必ずしもext4ファイルシステムを作成するわけではありませんが、拡張子2ファイルシステム。

Ubuntu 18.04が/etc/mke2fs.conf私のDebian 10と基本的に同じファイルを持っていると仮定すると、dir_indexmodernを使用して作成されたすべてのext2/3/4ファイルシステムの現在の基本機能セットとしてすでに有効になっていますmke2fs。また、dir_nlinkデフォルトで有効になっています。拡張子4ファイルシステムの種類。

マニュアルmke2fs.conf(5)ページには次のように書かれています。「ユーザーとmke2fs.confファイルの両方がデフォルトのファイルシステムタイプを指定しない場合は、mke2fsデフォルトのファイルシステムタイプが使用されます。拡張子3ジャーナルがコマンドラインオプションで要求された場合、または拡張子2そうでなければ。」

ファイルによると/etc/mke2fs.conf、-T newsオプションはオプションのみを指定しinode_ratio = 4096、他には何も指定しません。したがって、mkfs.ext4プレーンな の代わりに 形式を使用しない限りmke2fs、拡張子2平均サイズが 4 KB 以下のファイル向けにカスタマイズされたファイルシステム。

Debianにはのセクションfs_type =で指定されたがなく、コマンドにオプションが含まれていないため、UbuntuのがDebianのものと同じである場合（通常はそうです）、コマンドによって24TBが返される可能性があります。[defaults]mke2fs.conf-jmke2fsmke2fs.conf拡張子2ファイルシステムは、おそらく誰にも十分にテストされていないものです。

マニュアルext4(5)ページには、64bitファイルシステム機能は必要に応じて自動的に設定されると記載されており、これがツールがエラーを報告しなかった理由かもしれません。また、このdir_index機能は ext2 ファイルシステムでは無視されると記載されています。

マルチテラバイトのext3ファイルシステムでの過去の経験から、ファイルシステムの作成とチェックに膨大な時間がかかることが予想されます。 使用ケースによっては、この機能の有無によってdir_indexアプリケーションのパフォーマンスが左右される可能性があります。

tune2fs -l /dev/sdb1何が起こったか、起こらなかったかを推測する必要がないように、元の質問の実際の出力を編集していただけますか?

「構造をクリーニングする必要があります」は、ファイルシステムが破損しており、ファイルシステムのチェックが必要であることを示すカーネル エラー コードに対応するデフォルトのテキストのようですEUCLEAN。このサイズのファイルシステムでは、これにはかなりの時間と RAM が必要になります。そしてもちろん、チェック中はファイルシステムをアンマウントする必要があります。

答え2

実際、多くのテストを行った結果、ext4 にはそのようなこと (1 つのディレクトリに数十億のファイルを保持すること) を行う能力がないことが判明しました。Linux でこれを行う方法について調査した結果 (実際のテストでも)、このようなシナリオでは、このタスクを実行するために構築された ext4 ではなく XFS を使用する必要があることがわかりました。

関連情報