Wiki

스토리지 및 GC

Files 탭의 Storage 뷰: 리포지토리별 스토리지 대시보드(크기, 중복 제거, 증가)와 가비지 컬렉션, 오래된 리비전·고아 chunks·phantom files 정리.

소개

Storage 뷰는 리포지토리(서버에서 버전 관리되는 프로젝트)의 디스크 사용량을 보여주며, 오래된 리비전과 더 이상 쓸모없어진 데이터를 정리해 공간을 회수하는 가비지 컬렉션(GC) 도구를 제공합니다.

찾는 위치 PROJECT 행의 선택기에서 리포지토리를 고르고, 같은 행의 Files 탭을 연 다음, 탭 상단의 Browse / Storage 두 버튼으로 Storage 뷰로 전환합니다. Browse 뷰는 리포지토리의 파일을 탐색하는 용도이며, 이 페이지가 설명하는 모든 것은 Storage 뷰에 있습니다.

상단에 Browse와 Storage 두 버튼이 있는 Files 탭. Storage가 활성 버튼.

접근 권한과 역할

Files 탭과 그 Storage 뷰는 슈퍼 관리자와, 자신이 관리하는 리포지토리에 대한 project_admin이 사용할 수 있으며 GC 실행도 포함됩니다. 반면 서버 전역 통계와 라이선스는 슈퍼 관리자에게만 한정됩니다(패널의 다른 곳에 있음).

메트릭

Storage 뷰는 세 개의 카드, Total Size, Files / Revisions, Dedup Ratio로 시작합니다. 이어서 Growth (Last 30 Days) 히스토그램, 그다음 Largest Files 표가 나옵니다. 왼쪽 위의 새로고침 버튼이 전체를 다시 계산합니다.

Storage 뷰: 상단에 Total Size, Files / Revisions, Dedup Ratio 세 카드, 그 아래 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 뷰 하단에 있습니다. 두 가지 매개변수에 따라 오래된 이력을 정리합니다:

매개변수	기본값	역할
Retention (days)	90	이보다 경과일이 적은 리비전은 항상 유지됩니다.
Min revisions to keep	5	경과일과 무관하게 파일마다 유지되는 최근 리비전 수.

GC는 파괴적이며 되돌릴 수 없습니다 정리된 리비전(보존 창을 넘어선 것)은 복구할 수 없으며, Run GC는 어떤 확인도 요구하지 않습니다: 클릭만으로 실행됩니다. 실행할 때마다 Preview를 실행하고 수치가 예상과 일치하는지 확인하세요.

1. 두 매개변수 설정하기

버튼 왼쪽의 두 필드에 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를 참조).