Subversionリポジトリを保存するために使用される4 TBファイルシステムを備えたLinuxサーバーがあります。多くのリポジトリがあり、そのいくつかは数年間使用されています。
ディスクは元々約1 TBでしたが、約1年前に空き容量がなくなって4 TBに増加しました。現在、人々はリポジトリにファイルをチェックインできないと報告しています。エラーメッセージはNo space left on deviceです。
ディスクには約1.5 TBの空き容量があり、空きiノードがあることも報告されますが、新しいファイルを作成することはできません。古いファイルを更新することはまだ可能であり、断続的に一部のリポジトリが更新されますが、同じリポジトリが次の試行で失敗する場合があります。
回答:
問題は、XFSがiノードを割り当てる方法にあります。ほとんどのファイルシステムとは異なり、新しいファイルが作成されると割り当ては動的に行われます。ただし、特に指定しない限り、iノードは32ビット値に制限されています。つまり、ファイルシステム上のストレージの最初のテラバイトに収まらなければなりません。そのため、最初のテラバイトを完全に満たしてからディスクを拡大した場合、新しいスペースに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には0から始まる割り当てグループ（AGとも呼ばれます）があります。各AGのブロックサイズとブロック数を確認して、を使用して最初のテラバイトにあるグループを把握できxfs_info /path/to/mountpointます。または、最初のいくつかのAGをチェックして、どれがいっぱいかを確認してから、それらをクリアすることができます。
`seq 0 1 5`のag; AG $ agでエコーの空きスペースを行います。xfs_db -r -c "freesp -s -a $ ag" / dev / CACHE / CACHE; grep "total free"; やった
グループの合計空き容量が40未満の場合、そのグループに新しいファイルを作成することはできません。
これには、ファイルシステム上の各ファイルのメタデータを確認する必要があります。それが取る長い時間を...ここに提案があります：
find / extra -mindepth 3 -type f -exec xfs_bmap -v {} \; > /tmp/agfilelist.txt
次に、grep for " 0 "（スペース、ゼロ、および別のスペース）を使用してAG 0のすべてのファイルを検索し、grep for " 1 "を使用してAG 1のファイルを検索します。mv、ではありませんcp！）そして再び戻ります。かなりの空き容量ができるまで繰り返します。
/ extraから十分なファイルを移動し、再び元に戻すと、AG 0に多くのスペースがあり、新しいファイルを作成することが再び可能になりました。