[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

FreeBSD の スナップショットを保持している ufs がいっぱいになるとファイルが飛ぶ2024年04月17日 12時15分43秒

FreeBSD の UFS にもスナップショットを取る機能がある。UFS は古いファイルシステムなので、スナップショットは後付けだ。以前から不思議なシステムパニックに出会うことがあったが、最近何度か遭遇してかなり確信度があがった。

パニックの再現方法なのだが、UFS スナップショットを取った後にパーティション容量を使い尽くすこと。5% 程 UFS は予備でユーザが書き込めない分があるので、これには root ユーザで行う必要がある。ファイルシステムに書き込む場所がなくなればパニックが起こる。そして、fsck -yを行うと、どうもクラッシュ前のファイルが大量に消失してしまうようだ。

まだ、確信は無いのだが、どうも存在していたスナップショットに戻ってしまった模様。しかし、一つしかスナップショットが無い状態でのパニックしか経験していないので、二つ以上あった場合の動作がどうなるかは判らない。

なぜ、root ユーザで作業を行っていたかと言うと、/usr/local に割り当てた部分だったから。pkg の更新を行っていたのだ。そして、以前に作成したスナップショットが消されていないのに気が付かなかった。スナップショットが無ければ pkg delete が呼ばれた時点で容量が減る。しかし、スナップショットがあった為、pkg delete でも容量は減らない。容量の低下に気が付いて、急遽行ったいらないファイルの削除はむしろ墓穴を掘っただけだった。

取り敢えず、もう少し様子を見てから、bugzilla で検索をかけてみるつもり。

コメント

_ Tomoaki AOKI ― 2024年04月18日 18時07分08秒

関連するコードを読んでいないので記憶違いかもしれませんが、そもそもUFSにスナップショットが実装されたのはバックグラウンドfsckのためで、fsckがスナップショットを作成してそのまま後続処理を進めさせつつ、自身はスナップショットを対象にチェックを進め、修正内容があれば後続処理での変更と同様に反映して完了したらスナップショットを削除、という処理だったと記憶しています。
今回のケースでは空き容量が足りずスナップショットを作成できなかったため、本来そこでエラー処理としてスナップショットを使わない旧来の(フォアグラウンド前提の)処理に行くべきところ、既存最新のスナップショットを対象に処理を実行した挙げ句、rootしか使えない空きを食いつぶし始めて以降を異常と見做して最新のスナップショットまで戻し、自身が作ったわけではないスナップショットはそのままにしていた、とすれば辻褄が合いそうですね。

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://uyota.asablo.jp/blog/2024/04/17/9676556/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。