왜 파일 수가 많으면 디스크 공간보다 먼저 홈 NAS의 아이노드가 소진될까요?

파일 수가 많으면 데이터 블록이 소진되기 전에 가정용 NAS의 아이노드 공급이 고갈될 수 있습니다. 결과는 모순적으로 보일 수 있습니다: 용량 화면에는 기가바이트 또는 테라바이트가 남아 있지만, 업로드, 백업, 컨테이너 또는 인덱싱 작업이 더 이상 새 파일을 생성할 수 없습니다.

이는 모든 NAS의 보편적인 특성이 아니라 파일 시스템 제한입니다. 고전적인 실패 사례는 정의된 아이노드 수를 가진 ext4 및 유사 파일 시스템에서 가장 쉽게 볼 수 있으며, XFS와 Btrfs는 메타데이터를 다르게 할당합니다. 따라서 파일 시스템 유형에 따라 “자유 아이노드”가 올바른 지표인지 아니면 진단의 일부인지 결정됩니다.

가정용 NAS는 데이터 블록보다 먼저 객체 슬롯을 소진할 수 있습니다

직접적인 원인은 파일 데이터와 파일 식별자가 서로 다른 자원을 소비하기 때문입니다. ext4에서 아이노드는 타임스탬프, 소유권, 블록 매핑, 확장 속성 같은 메타데이터를 기록하며, 디렉터리 항목은 이름을 아이노드와 연결합니다. 리눅스 커널의 ext4 아이노드 문서는 아이노드 테이블을 블록 그룹에 분산된 선형 배열로 설명합니다.

새로운 일반 파일은 보통 아이노드가 필요하지만, 바이트 크기가 필요한 아이노드 수를 결정하지는 않습니다. 100GB 비디오는 하나의 아이노드를 차지할 수 있지만, 백만 개의 작은 캐시 파일은 대략 백만 개의 아이노드를 필요로 할 수 있습니다. 디렉터리와 심볼릭 링크도 파일 시스템 객체이며, 동일 파일에 대한 여러 하드 링크는 하나의 아이노드를 공유합니다.

따라서 마지막 자유 아이노드가 할당된 후에도 자유 블록은 여전히 사용 가능할 수 있습니다. 이 시점에서 NAS는 원칙적으로 더 많은 파일 콘텐츠를 저장할 공간이 있지만, 또 다른 객체를 생성하는 데 필요한 메타데이터 식별자가 부족합니다. 용량과 객체 수는 독립적이므로 둘 다 관찰해야 합니다.

작은 파일이 용량보다 아이노드 사용을 더 빠르게 증가시키는 이유

작은 파일은 높은 객체 밀도를 만듭니다: 비교적 적은 데이터에 많은 식별자가 필요합니다. 0바이트 파일도 메타데이터가 필요하며, 디렉터리 트리는 내부 파일 수를 세기 전에 자체 디렉터리 아이노드를 추가합니다. 이 때문에 작업 부하는 NAS의 광고된 테라바이트 용량보다 훨씬 빠르게 파일 슬롯을 소모할 수 있습니다.

ext4에서는 생성 도구가 바이트당 inode 비율에서 inode 수를 계산하거나 명시적인 inode 수를 받을 수 있습니다. mke2fs inode 할당 옵션에 따르면, 바이트당 inode 비율이 클수록 inode 수가 적어지고, 파일 시스템 생성 후에는 비율을 변경할 수 없지만, 크기 조정 시 새 공간에 inode를 추가하여 구성된 비율을 유지합니다.

간단한 계획 모델은 대략적인 inode 수 = 파일 시스템 크기 ÷ 바이트당 inode 비율입니다. 가상의 16 KiB 비율을 적용하면 1 TiB는 포맷 오버헤드와 파일 시스템 제한을 고려하기 전 약 6,700만 개의 inode 슬롯에 해당합니다. 이는 예시일 뿐이며, 보편적인 NAS 기본값은 아닙니다: 포맷 프로필과 파일 시스템 구현은 서로 다른 정책을 선택합니다.

마지막 여유 inode가 할당되면 무엇이 변하는가

고전적인 고갈 사례에서는 새 inode가 필요한 작업이 실패하기 시작합니다. 새 업로드, 디렉터리, 임시 파일, 추출된 아카이브 멤버 및 애플리케이션 상태 파일이 모두 거부될 수 있지만 기존 파일은 여전히 읽을 수 있습니다. 기존 파일도 이미 inode를 소유하고 있고 여유 데이터 블록이 남아 있다면 크기를 늘릴 수 있습니다.

애플리케이션은 종종 할당 실패를 일반적인 “장치에 남은 공간 없음” 메시지로 변환합니다. 이 메시지는 실패한 자원 할당을 나타내지만, 누락된 자원이 데이터 블록, inode, 할당량 허용치 또는 파일 시스템별 메타데이터 공간 중 무엇인지 사용자에게 알려주지 않습니다. 표시된 오류는 파일 시스템 카운터와 함께 확인해야 합니다.

어떤 홈 NAS 작업 부하가 극단적인 파일 수를 생성하는가

위험한 작업 부하는 단순히 “대용량 데이터”가 아닙니다. 특히 정리나 보존이 수개월 동안 객체가 누적되도록 허용할 때 많은 독립적인 파일 시스템 객체를 생성하는 모든 작업 부하가 위험합니다.

컨테이너 레이어, 로그 및 패키지 트리

컨테이너 이미지, 추출된 소프트웨어 패키지, 의존성 트리, 순환 로그 및 애플리케이션 캐시는 하나의 NAS 호스팅 서비스 아래에 많은 수의 작은 객체를 배치할 수 있습니다. 컨테이너 이미지는 기가바이트 단위로는 작아 보일 수 있지만, 풀린 레이어와 쓰기 가능한 상태는 같은 크기의 미디어 파일보다 훨씬 더 많은 객체 ID를 소비합니다.

사진 썸네일 및 검색 인덱스

사진 관리자는 각 원본 자산에 대해 썸네일, 미리보기, 사이드카, 얼굴 자르기 또는 인덱스 조각을 생성할 수 있습니다. 일부 애플리케이션은 이러한 기록을 데이터베이스에 통합하는 반면, 다른 애플리케이션은 많은 기록을 일반 파일로 저장하므로 inode 효과는 사진 라이브러리 크기뿐만 아니라 애플리케이션의 저장 설계에 따라 달라집니다.

동기화 기록, 백업 트리 및 메일 저장소

파일로서 개정을 구현하는 버전 관리 시스템, 많은 소스 객체를 포함하는 백업 트리, 그리고 파일당 하나의 메시지를 저장하는 메일 저장소는 모두 높은 파일 수를 생성할 수 있습니다. 복사 시 쓰기 스냅샷과 중복 제거된 저장소는 버전을 다르게 표현할 수 있으므로, 스냅샷 수를 구현을 확인하지 않고 직접적인 아이노드 수로 간주해서는 안 됩니다.

용량 대시보드가 아이노드 압박을 놓치는 이유

많은 대시보드는 바이트 단위(총 용량, 사용된 블록, 여유 블록)를 강조합니다. 표준 파일시스템 통계 인터페이스는 객체 카운터를 총계, 여유, 사용 가능 파일 일련 번호로 별도로 유지하며, 리눅스에서는 f_files 및 f_ffree와 같은 필드에 해당합니다. 이러한 필드를 생략하는 UI는 고전적인 아이노드 고갈 시에도 정상으로 보일 수 있습니다.

셸 액세스가 가능한 리눅스 기반 NAS에서 동일한 마운트 경로에 대해 블록 사용량과 아이노드 사용량을 비교할 수 있습니다:

df -h /path/on/nas
df -i /path/on/nas

GNU df 매뉴얼은 -i를 블록 사용 대신 아이노드 사용으로 정의하며 총계, 사용, 사용 가능 및 백분율 필드를 노출합니다. 여유 아이노드가 0인 상태에서 여유 블록이 있는 경우 고전적인 아이노드 고갈을 강력히 지지하며, 두 열 모두에 여유가 있다면 다른 한계점을 가리킵니다.

고정 및 동적 아이노드 파일시스템은 다르게 실패합니다

“NAS가 아이노드를 모두 사용했다”는 파일시스템의 할당 모델과 보고된 카운터가 이를 지원할 때만 정확합니다. 동일한 공간 부족 메시지는 다른 파일시스템의 다른 메타데이터 경계에서 발생할 수 있습니다.

XFS 아이노드 공간 정책은 아이노드에 할당된 파일 시스템 비율을 제한할 수 있으며, 공식 Btrfs 파일 시스템 보고서는 데이터, 시스템, 메타데이터, 글로벌 예약 공간을 구분합니다. 이러한 모델은 메타데이터 관련 제한을 만들 수 있지만, 모든 NAS가 동일한 고정 아이노드 테이블을 가진 것처럼 설명해서는 안 됩니다.

일반 통계 인터페이스는 반환된 모든 필드가 모든 파일 시스템에서 의미가 있는 것은 아니라고도 경고합니다. 먼저 마운트된 파일 시스템을 식별한 후 해석하세요. df -i 하나의 명령을 보편적인 증거로 취급하지 않고 그 구현을 통해 처리합니다.

NAS 용량 계획에서 아이노드 여유 공간이 의미하는 바

고객체 작업 부하에 대한 용량 예측은 예상 바이트와 예상 객체 수 모두가 필요합니다. 미디어 아카이브는 보통 바이트 밀도가 높고, 의존성 트리, 썸네일, 메일 저장소, 물리적 백업 트리는 객체 밀도가 높을 수 있습니다. 따라서 동일한 논리적 크기의 두 작업 부하는 매우 다른 메타데이터 여유 공간을 필요로 할 수 있습니다.

ext4 볼륨의 경우, 바이트당 아이노드 비율은 포맷 시점에 결정되는 설계 선택이며 일반적인 실시간 조정 수단이 아닙니다. 크기 조정은 설정된 비율에 따라 아이노드를 추가할 수 있지만, 기존 비율을 더 조밀하게 변경하지는 않습니다. 그 비율을 변경하기 위해 재포맷하는 것은 백업 및 복원과 관련된 마이그레이션 결정이지 단순한 성능 조정이 아닙니다.

아이노드 압박이 배제된 후에는 일반적인 블록 용량 문제는 별개로 남아 있습니다; 홈 NAS 저장 용량 계획이 그 결정을 보완할 수 있지만, 자유 테라바이트 지침은 아이노드나 메타데이터 수를 대체하지 않습니다.

하나의 큰 파일을 삭제해도 충분한 아이노드를 복구하지 못하는 이유

하나의 큰 영화를 삭제하면 많은 데이터 블록이 해제될 수 있지만 일반적으로 하나의 아이노드만 해제됩니다. 수십만 개의 불필요한 캐시 객체를 포함하는 디렉터리 트리를 제거하면 복구된 바이트 용량이 비교적 작더라도 많은 아이노드를 해제할 수 있습니다. 정리는 소진된 자원에 맞춰야 합니다.

연결이 끊긴 객체가 항상 즉시 회수되는 것은 아닙니다. Linux unlink 동작은 프로세스가 마지막 링크를 여전히 열고 있을 때 파일을 유지하며, 마지막 참조 파일 디스크립터가 닫힌 후에 해제합니다. 따라서 inode 회수는 활성 로그나 서비스 파일의 경로 이름 삭제보다 늦을 수 있습니다.

자주 묻는 질문

모든 파일이 정확히 하나의 inode를 사용하나요?

일반 파일은 보통 하나의 inode를 가지며, 디렉터리와 심볼릭 링크도 자체 파일시스템 ID를 가집니다. 여러 하드 링크 이름이 동일한 inode를 가리킬 수 있고, 파일시스템별 기능은 별도의 객체에 추가 메타데이터를 저장할 수 있으므로 경로 이름 수와 inode 수는 관련 있지만 항상 동일하지는 않습니다.

SSD 캐시나 더 빠른 네트워크가 inode 고갈을 방지할 수 있나요?

아닙니다. 더 빠른 미디어와 네트워킹은 지연 시간을 줄이거나 처리량을 늘릴 수 있지만 고정된 inode 수에서 추가 inode 슬롯을 생성하지는 않습니다. 높은 파일 수 작업 부하가 더 빨리 완료되어 동일한 메타데이터 한도에 더 빨리 도달할 수 있습니다.

작동하나요? df -i 모든 홈 NAS 파일시스템에서 작동하나요?

마운트된 파일시스템 인터페이스를 통해 제공되는 inode 스타일 카운터를 보고하지만, 이 카운터는 모든 파일시스템에서 동일한 의미를 갖지 않을 수 있습니다. ext4 스타일 진단에는 직접 사용하고 XFS, Btrfs, ZFS 또는 기본 볼륨을 추상화하는 어플라이언스용 파일시스템별 메타데이터 도구와 함께 사용하세요.

ext4 파일시스템 확장이 더 많은 inode를 추가할 수 있나요?

네, ext4 크기 조정은 기존 바이트당 inode 비율을 유지하면서 새 공간이 통합될 때 inode를 추가할 수 있습니다. 이는 생성 도구 문서에서 포맷 후 지원하지 않는다고 명시한 기존 파일시스템의 비율 변경과 다릅니다.

모든 “장치에 남은 공간 없음” 오류가 inode 때문인가요?

아닙니다. 가득 찬 데이터 블록, 할당량, 예약 공간, Btrfs 메타데이터 할당, 임시 공간 제한 및 일부 비저장 리소스 제한도 유사한 메시지를 발생시킬 수 있습니다. inode 고갈은 실패가 파일시스템 객체 생성과 관련되고 해당 inode 카운터에 사용 가능한 항목이 없을 때 지원됩니다.

파일 수는 자체 용량 차원입니다

홈 NAS는 디스크 공간이 남아 있어도 바이트와 파일시스템 메타데이터가 별도의 용량 차원이기 때문에 새 객체 수락을 중단할 수 있습니다. 높은 파일 수를 작업 부하 특성으로 간주하고 실제 파일시스템을 확인한 후 블록 여유 공간과 inode 또는 메타데이터 여유 공간을 비교하여 디스크가 가득 찼는지 결론을 내리세요.