Capordia역할과 소유자별로 파일 분류하기
처리에 필요한 입력 파일, 중간 파일, 보존할 결과물을 구분합니다. 입력은 저장소나 아카이브에서 올 수 있고, 임시 파일은 재생성할 수 있으며, 결과물에는 영구적인 저장 위치가 필요합니다. 여기에 네 번째 범주를 추가합니다. 바로 실행을 재개할 수 있게 해주는 상태입니다. 재개 지점은 원본 입력과도, 최종 결과물과도 다른 것입니다.
각 범주마다 소유자와 보존 규칙을 정합니다. 누가 캐시 삭제를 승인할 수 있습니까? 누가 결과물이 활용 가능한지 확인합니까? 작업이 중단되면 어떤 파일이 없어집니까? 이러한 답변을 저장 위치와 함께 프로젝트 문서에 기록해 둡니다. 카탈로그에는 GPU가 설명되어 있지만, 디스크 용량, 할당량, 보존 조건은 실제로 제공되는 범위에 대해 확인해야 합니다.
초기 아카이브만이 아니라 스토리지 최대치 계산하기
실행 중 최대 용량을 평가합니다. 압축 해제된 이미지, 작업 사본, 연속된 버전들이 수신한 아카이브보다 더 많은 공간을 차지할 수 있습니다. 올바른 계산은 동시에 공존하는 요소들을 더하는 것입니다. 서로 배타적인 단계를 합산해서는 안 되며, 처리가 아직 결과물을 생성하는 동안 내보내기가 준비될 수 있다는 점도 잊지 말아야 합니다.
가상의 예시로, 소수점이 있는 GB 단위를 사용합니다. 한 팀이 420GB의 압축 해제된 파일을 준비하는 동안 180GB의 아카이브를 보관합니다. 이들은 120GB의 임시 파일, 60GB의 출력물, 24GB짜리 재시작 지점 세 개를 예상합니다. 모두 동시에 존재할 경우 최대치는 180 + 420 + 120 + 60 + 72 = 852GB입니다. 내부적으로 선택한 20% 여유분을 적용하면 필요 용량은 1,022.4GB가 됩니다. 이 프로젝트 가정은 어떤 요금제에도 포함된 용량이 아닙니다.
| 범주 | 계산 | 용량 |
|---|---|---|
| 보존된 입력 아카이브 | 1 × 180GB | 180GB |
| 압축 해제된 입력 | 1 × 420GB | 420GB |
| 최대치 시점의 임시 파일 | 작업 가정 | 120GB |
| 준비 중인 결과물 | 작업 가정 | 60GB |
| 재개 지점 | 3 × 24GB | 72GB |
| 여유율 적용 전 합계 | 다섯 범주의 합계 | 852GB |
연속 작업을 시작하기 전에 사용 가능한 위치 확인하기
프로젝트를 실제로 호스팅할 파일 시스템의 사용 가능한 공간을 확인한 다음, 쓰기 권한과 예상되는 최대 파일 크기를 점검합니다. 아주 작은 파일이 많을 경우 시스템이 아이노드를 사용한다면 아이노드 가용성도 확인합니다. GNU df는 사용 가능한 블록과 아이노드를 구분합니다. 바이트 단위의 용량 지표가 파일 생성 실패의 모든 원인을 요약해 주지는 않습니다.
Linux와 GNU 도구가 있다면 아래 명령어로 현재 디렉터리를 읽기 전용으로 점검할 수 있습니다. 확인한 시각과 경로를 기록해 둡니다. 이러한 점검은 스토리지 속도를 측정하지 않으며 공간을 예약하는 것도 아닙니다. 추가 할당량이 적용될 수도 있습니다. 준비가 끝났다고 판단하기 전에 그 범위를 확인하세요.
df -B1 --output=source,size,used,avail,pcent,target .
df -i .팀이 다시 확인할 수 있는 이름과 상태 정리하기
결과물에 배치와 처리 버전을 식별할 수 있는 이름을 붙입니다. 진행 중인 파일과 검증된 납품물을 분리합니다. 납품 폴더에는 승인된 결과와 같은 이름을 가진 부분 사본이 섞여서는 안 됩니다. 대장에는 데이터 자체를 담지 않으면서 배치 식별자, 코드 버전, 위치, 검증 상태를 연결할 수 있습니다.
장시간 계산의 경우 애플리케이션이 생성할 수 있는 재개 지점을 정의하고 그 읽기를 확인합니다. 저장된 상태와 함께 필요한 매개변수를 보존합니다. 프로세스가 파일에 아직 쓰고 있는 동안 복사한다면, 애플리케이션이 마련한 메커니즘 없이는 그 복사본을 일관된 상태로 간주해서는 안 됩니다. 완료되고 식별된 백업을 선호하고, 그 이름을 다음 단계를 준비하는 사람에게 전달하세요.
결과물의 전송과 활용을 각각 따로 점검
마지막 날 이전에 첫 결과물을 최종 목적지로 전송하세요. 예상 파일 목록과 각 크기를 비교하고, 절차에 명시되어 있다면 체크섬도 비교하세요. GNU의 SHA-2 도구는 파일 체크섬을 계산하고 검증합니다. 매니페스트는 완료된 파일과 일치해야 하며 출처가 명확한 상태로 보관해야 합니다. 매니페스트만으로는 콘텐츠의 업무적 품질이 검증되지 않습니다.
무결성 점검 후, 결과물을 실제로 사용할 애플리케이션으로 목적지에서 열어 보세요. 항목 수, 형식, 외부 의존성을 확인하세요. 완벽하게 복사된 압축 파일이라도 처음부터 파일이 하나 빠져 있을 수 있습니다. 따라서 수령 담당자는 두 가지를 각각 확인해야 합니다. 복사본이 예상 패키지와 일치하는지, 그리고 그 패키지가 다음 단계에 실제로 쓰이는지입니다.
sha256sum --check MANIFEST.sha256기간 종료 전에 보존 여부 결정
852GB 예시에서 독립적인 복사본이 확인된 후 작업용 압축 파일을 삭제하면 여유 공간을 고려하기 전에 필요한 용량이 672GB로 줄어듭니다. 이 절감은 압축 파일의 복원이 여전히 가능하고 이후 단계에서 현장에 그 파일이 필요하지 않은 경우에만 유효합니다. 결정은 데이터 소유자가 내려야 하며, 공간 부족을 발견한 사람이 즉흥적으로 처리해서는 안 됩니다.
흔한 실수는 모든 버전을 제한 없이 보관하는 것, 목적지 권한 테스트를 마지막까지 미루는 것, 같은 위치에 있는 복사본을 백업 솔루션으로 간주하는 것입니다. 보관할 목록, 내보내기 담당자, 최종 점검을 정하세요. 3일, 7일, 30일 어느 경우든 계산 기간과 복구 기간은 같은 일정에 포함됩니다.
결정을 위한 질문
임시 파일을 모두 보관해야 하나요?
반드시 그렇지는 않습니다. 애플리케이션이 재생성할 수 있는 파일을 식별한 다음, 그 용량을 재생성 비용 및 시간과 비교하세요. 검증된 재개에 필요한 항목은 보관하세요. 아직 사용 중인 파일이나 필수 상태를 삭제하는 것은 정리 규칙에서 제외해야 합니다.
체크섬이 맞으면 내보내기를 수락해도 되나요?
체크섬은 예상 값과 일치하는지 검증합니다. 매니페스트가 올바른 파일을 포함하는지, 결과물이 의존성과 함께 열리는지는 아직 확인해야 합니다. 따라서 수락은 패키지 무결성과 목적지에서의 기능 점검을 함께 판단합니다.
GPU 메모리가 부족한 디스크 공간을 대체할 수 있나요?
아니요. VRAM은 카드에서 계산에 사용되는 데이터를 담는 공간입니다. 파일의 목적지나 임대 기간 이후의 보존을 대체하지 않습니다. 문서에는 GPU 메모리, 시스템 메모리, 스토리지를 각각 구분해 기술하세요.