OpenSolarisでファイルを削除するときにデバイスにスペースがない

（OpenIndianaサーバーからエクスポートされた）NFS共有をクライアントボックスにマウントしようとすると、OIサーバーがクラッシュしました。ログダンプのような死の黒い画面が表示された後、システムが再起動しました。起動しないので、ブートを停止した後、次のエラーメッセージが表示されます。

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

OS以外に起動ドライブに他に何もないので、ドライブがいっぱいになる可能性があるかわかりません。多分何かのログファイル？何も削除していないようです。何かを削除しようとすると、スペースエラーが発生します。

$ rm filename
cannot remove 'filename' : No space left on device 

「メンテナンスモード」にログインできますが、標準のユーザープロンプトにはログインできません。

の出力dfは次のとおりです。

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

の出力mountは次のとおりです。

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

「zfs list -t all」の出力は次のとおりです。

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

OK、それは奇妙なことです...ファイルを削除するのに十分なスペースがありません！

これはZFSで比較的一般的な問題であることがわかりますが、 スナップショットを持つファイルシステムで発生する可能性があります。

説明は、削除しようとしているファイルがスナップショットにまだ存在していることです。したがって、それを削除しても、コンテンツは（スナップショットのみ）に存在し続けます。システムは、スナップショットにファイルがあるが、現在の状態にはないという情報をさらに書き込む必要があります。その余分な情報のためのスペースは残っていません。

短期的な修正は、最新のスナップショットの後に作成されたファイルを見つけて削除することです。別の可能性は、最新のスナップショットの後に追加されたファイルを見つけて、最新のスナップショットの時点でのサイズに切り捨てることです。ログがスパムされているためにディスクがいっぱいになった場合は、最大のログファイルをトリミングしてみてください。

より一般的に適用可能な修正は、いくつかのスナップショットを削除することです。でスナップショットを一覧表示できますzfs list -t snapshot。特定のスナップショットを破棄した場合にどれだけのスペースが回復するかを予測する簡単な方法はないようです。格納されているデータが他のスナップショットで必要となる場合があり、そのスナップショットを破棄した場合でも、そのデータが存続する可能性があるためです。したがって、必要に応じてデータを別のディスクにバックアップし、不要になった1つ以上のスナップショットを特定して、を実行しzfs destroy name/of/snap@shotます。

この問題については、このOpenSolarisフォーラムスレッドで詳しく議論されています。

これは、コピーオンライトファイルシステムのよく知られた問題です。ファイルを削除するには、ファイルシステムはまずブロックを割り当て、新しいステータスを修正してから、削除中のファイル内に含まれている豊富なスペースを解放する必要があります。

（これは、コピーオンライト以外にスナップショットを実装する他の方法があるため、スナップショットを使用するファイルシステムの問題ではありません）

圧迫から抜け出す方法：

• スナップショットをリリースします（存在する場合...）
• プールを拡張します（割り当て可能なスペアが残っている場合）
• プール内の別のファイルシステムを破棄してから、タイトなファイルシステムを拡張する
• ファイルを切り詰めてから削除します（ただし、締めすぎてそれを実行できない場合は、ZFSディスカッションのスレッドを参照してください）
• ファイルのリンクを解除します。（同上）

私は数年前に同じ罠に遭遇しました、そして私を解放するためにリリースすることができたスナップショットがありませんでした。この問題が詳細に議論されたZFSディスカッションのスレッドを参照してください。

4.Z3G（rpool / root USEDカラム）は疑わしいです。

いずれにせよ、rpool / export / home / adminが大きすぎる（3.85 GB）ことが根本的な原因である可能性があります。その内容を見て、そこで不要なファイルを削除してください。adminファイルシステムにはスナップショットがないため、これによりプール内のスペースがすぐに解放されます。

私にはそれがあり、何が必要かを理解するためにしばらくの間費やしました。私の解決策は、ファイルを削除する前に、ファイルのスペースをゼロにすることでした。

時々おかしくなり、ディスクにコアファイル（数字で終わる）がいっぱいになるいくつかの誤動作プロセスがあるため、1つのコピーを保持するために、このようなものを含むスクリプトを作成しました。

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

スクリプトを実行すると、1つのエラーが発生しました。

mv: cannot rename core.200000 to core: No space left on device

ファイルをクリアする機能でした。

これをテストするために、ディスクを次のように満たしました。

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done