Wiki

ストレージと GC

Files タブの Storage ビュー：リポジトリごとのストレージダッシュボード（サイズ、重複排除、増加）とガベージコレクション、古いリビジョン・孤立した chunks・phantom files の削除。

はじめに

Storage ビューはリポジトリ（サーバー上でバージョン管理されたプロジェクト）のディスク使用量を表示し、古いリビジョンや不要になったデータを削除して容量を取り戻すための ガベージコレクション（GC）ツールを提供します。

見つけ方 PROJECT の行のセレクターでリポジトリを選び、同じ行の Files タブを開き、タブ上部の Browse / Storage の 2 つのボタンで Storage ビューに切り替えます。Browse ビューはリポジトリのファイルを参照するためのもので、このページで説明する内容はすべて Storage ビューにあります。

上部に Browse と Storage の 2 つのボタンがある Files タブ。Storage がアクティブなボタン。

アクセスとロール

Files タブとその Storage ビューは、スーパー管理者と、管理対象のリポジトリにおける project_admin が利用でき、GC の実行も含みます。一方、サーバー全体の統計とライセンスはスーパー管理者に限定されています（パネルの別の場所）。

メトリクス

Storage ビューは 3 つのカード、Total Size、Files / Revisions、 Dedup Ratio から始まります。続いて Growth (Last 30 Days) ヒストグラム、そして Largest Files テーブルが表示されます。左上の更新ボタンで全体を再計算します。

Storage ビュー：上部に Total Size、Files / Revisions、Dedup Ratio の 3 つのカード、その下に Growth (Last 30 Days) ヒストグラム、続いて Path、Size、Revisions の列を持つ Largest Files テーブル。

各数値の意味：

Total Size：ファイルの合計サイズ。すぐ下に、ディスク上で実際に占有している圧縮後のサイズ。
Files / Revisions：ファイル数。その下にリビジョン数と chunks 数。
Dedup Ratio（%）：chunks の共有と圧縮によって節約された容量の割合。
Growth (Last 30 Days)：日ごとの累積サイズ。バーにマウスを乗せると、その日付・サイズ・リビジョン数が読めます。
Largest Files：最大 20 件のファイルと、そのサイズおよびリビジョン数。

これらの数値は、膨らんでいくリポジトリを見つけるのに役立ちます：頻繁に再コミットされる大きなバイナリファイルや、直近 30 日間の異常な増加などです。

ガベージコレクション

Garbage Collection ブロックは Storage ビューの下部にあります。次の 2 つのパラメータに従って古い履歴を削除します：

パラメータ	デフォルト	役割
Retention (days)	90	これを下回る経過日数のリビジョンは常に保持されます。
Min revisions to keep	5	経過日数にかかわらず、ファイルごとに保持される最近のリビジョン数。

GC は破壊的で取り消せません 削除されたリビジョン（保持ウィンドウを超えたもの）は復元できず、Run GC は確認を求めません：クリックだけで実行されます。実行のたびに Preview を行い、数値が想定どおりであることを確認してください。

1. 2 つのパラメータを設定する

ボタンの左にある 2 つのフィールドに Retention (days) と Min revisions to keep を入力します。上の表のデフォルト値、90 と 5 で表示されます。注意：リビジョンは両方の条件が満たされた場合にのみ削除されます。

2. Preview でプレビューを実行する

Preview は何も削除せずに削除をシミュレートします。ボタンの下に黄色いバナーが表示されます：「Preview: X revisions would be deleted across Y files, Z phantom file entries would be removed」。ここで桁数を確認します。数値に驚いたら、実行するのではなく保持期間を上げてください。

Garbage Collection ブロック：Retention (days) と Min revisions to keep のフィールド、Preview と Run GC のボタン、その下にプレビューの黄色いバナー。

3. Run GC で実行する

赤い Run GC ボタンで削除を実行します。完了を示す緑のバナーに「GC complete: X revisions deleted, Y orphan chunks cleaned, Z phantom file entries removed」と表示され、上部のメトリクスが再読み込みされ、実行は監査ログに記録されます。

Run GC の後にボタンの下に表示される緑の GC complete バナー：削除されたリビジョン数、クリーンアップされた孤立 chunks 数、除去された phantom エントリ数。

GC が削除する対象

古いリビジョン：Retention (days) より古く、かつファイルごとに Min revisions to keep の最新分を超えたもの。続いてそれらの chunks が、他のどのリビジョンからも参照されていなければ削除されます。
孤立した chunks：削除後にどのリビジョンからも使われなくなったデータブロック。
Phantom files：実際にはコミットされなかったファイル行（無効なパス、または保留のまま残ったエントリ）で、固定の 7 日ウィンドウ（設定不可）を超えたもの。

削除または obliterate されたファイルの削除マーカー（tombstones）は保護されます：これらは sync の際にクライアントへ削除を伝播させるために使われるため、消えてはいけません。

よくある落とし穴

Preview がほとんど何も報告しない

リポジトリが新しい場合や、履歴が保持ウィンドウ内に収まっている場合は正常です。GC は、十分に古くかつファイルごとに最新 N 件を超えたリビジョンのみを対象にします。

Preview と Run でカウンタが一致しない

Preview は削除される chunks とリビジョン・chunk リンクの正確な数を予測できません：報告できるのはリビジョン、スキャンされたファイル、phantom エントリのみです。孤立した chunks は Run のときにのみ現れます。

容量を取り戻すために保持期間を下げる

可能ですが、履歴を失います。かなり過去まで遡れる必要があるプロジェクトでは、余裕のある保持期間を維持し、代わりに大きなファイルで調整してください（最大のファイルの一覧、および再生成可能な成果物のトラッキングを避けるための .uversionignore を参照）。