4 TBファイルシステムを備えたLinuxサーバーがあり、これはSubversionリポジトリーの保管に使用されます。多くのリポジトリーがあり、そのいくつかは数年使用されています。
ディスクは当初約1 TBでしたが、スペースが不足し始めて4に増やしましたTB約1年前。今、人々はファイルをリポジトリにチェックインできないと報告しています。エラーメッセージはNo space left on device
。
ディスクの空き容量は約1,5 TB= freeであり、inodeが空いていることも報告されます-しかし、その上に新しいファイルを作成することはできません。古いファイルを断続的に更新することは可能です。一部のリポジトリは更新されますが、同じリポジトリが次回の試行で失敗する可能性があります。
問題は、XFSがiノードを割り当てる方法にあることが判明しました。ほとんどのファイルシステムとは異なり、新しいファイルが作成されると、割り当ては動的に行われます。ただし、特に指定しない限り、iノードは32ビット値に制限されます。つまり、iノードはファイルシステムのストレージの最初のテラバイトに収まる必要があります。したがって、その最初のテラバイトを完全に埋めてからディスクを拡張すると、新しいスペースにiノードを作成できないため、新しいファイルを作成できなくなります。
1つの解決策は、マウントオプションinode64
を使用してファイルシステムを再マウントすることです。ただし、一部のアプリケーション(MySQLなど)は奇妙に動作し、NFSは非常に混乱します。したがって、システムがこのオプションで動作するかどうかわからない場合は、次のオプションに進むことができます。
2番目の解決策は、最初のテラバイトに現在格納されているファイルの一部を見つけて、ファイルシステムの別の領域に移動することです。
私たちの場合、これは簡単でした。ファイルシステムは何年も使用されていたため、最も古いファイルを見つけてファイルシステムから移動し、元に戻すことができました。これは、findを使用して簡単に実行できました。
find /extra -mindepth 3 -maxdepth 3 -type d -mtime +730 -exec du -sh {} \; > /tmp/olddirs.txt
2年以上前のマウントポイントの3レベル下のすべてのディレクトリのサイズとディレクトリ名を含むリストが表示されました。次に、リストを並べ替えて最大のディレクトリを見つけ、mv
を使用してそれらを別のファイルシステムに移動し、再び戻します。
あなたが単に年齢で行くことができないならば、例えば。同時に多数のファイルが作成された場合でも、移動する適切なファイルを見つけることができますが、少し時間がかかります。
XFSには割り当てグループ(別名[〜#〜] ag [〜#〜] s)があり、0から始まります。各AGのブロックサイズとブロック数を確認して、どのグループが最初のテラバイトではxfs_info /path/to/mountpoint
を使用します。または、最初のいくつかのAGをチェックして、どのAGがいっぱいであるかを確認し、それらをクリアすることもできます。
`seq 0 1 5`のagの場合; AG $ agの空き領域をエコーします。 xfs_db -r -c "freesp -s -a $ ag"/dev/CACHE/CACHE; grep "完全無料";できた
いずれかのグループの合計空き容量が40未満の場合、そのグループに新しいファイルを作成することはできません。
これには、ファイルシステム上の各ファイルのメタデータをチェックする必要があります。 long時間かかります...ここに提案があります:
find/extra -mindepth 3 -type f -exec xfs_bmap -v {} \; > /tmp/agfilelist.txt
次に、" 0 "
(スペース、ゼロ、および別のスペース)をgrepしてAG 0上のすべてのファイルを検索し、" 1 "
をgrepしてAG 1上のファイルを検索できます。 AG 0、最大のファイルを(mv
ではなくcp
を使用して)移動し、再度戻します。十分な空き容量ができるまで繰り返します。
/ extraから十分な数のファイルを移動してから再び戻したところ、AG 0には多くのスペースがあり、再び新しいファイルを作成することができました。