Unix 파일 시스템에는 일반적으로 inode 테이블이 있으며 이 테이블의 항목 수는 일반적으로 파일 시스템이 생성될 때 고정됩니다. 이로 인해 디스크 공간이 많은 사람들은 여유 공간이 없다는 혼란스러운 오류 메시지를 받게 되며, 문제가 무엇인지 알아내더라도 쉽게 해결할 수 있는 방법이 없습니다.
그러나 필요에 따라 inode를 할당하여 전체 혼란을 피하고 사용자와 시스템 관리자에게 완전히 투명하게 하는 것이 (나에게는) 매우 바람직해 보입니다. 깔끔한 트릭을 좋아한다면 inode 테이블 자체를 파일로 만들어 이미 가지고 있는 코드를 재사용하여 디스크에서 여유 공간을 찾을 수도 있습니다. 운이 좋다면 명시적으로 이 결과를 얻으려고 시도하지 않고도 파일 자체 근처에 인덱스 노드가 생길 수도 있습니다.
그러나 내가 아는 한 실제로는 아무도 이 작업을 수행하지 않으므로 문제가 누락되었을 수 있습니다. 그게 뭔지 아세요?
답변1
inode 테이블을 파일로 생성했다고 가정하면 다음 질문은...파일에 대한 정보를 어디에 저장합니까? 따라서 "실제" inode와 MS-DOS 파티션 테이블과 같은 "확장" inode가 필요합니다. 주어진 경우 하나만 필요합니다(또는 몇 개 - 예를 들어 일기장도 파일로 보관). 그러나 실제로는 특별한 경우, 다른 코드가 있을 것입니다. 이 파일이 손상되면 재앙이 될 수도 있습니다. 그리고 기록하기 전에 정전 등으로 인해 기록 중인 파일이 심각하게 손상되는 경우가 많다는 점을 고려하세요. 파일 작업은 다음과 같아야 합니다.많은정전/충돌 등에 비해 더욱 견고합니다. 예를 들어 ext2보다 더 그렇습니다.
기존 Unix 파일 시스템은 더 간단하고 더 강력한 솔루션을 찾았습니다. 즉, X 블록마다 하나의 inode 블록(또는 블록 그룹)을 배치하는 것입니다. 그런 다음 간단한 산술로 찾을 수 있습니다. 물론, (전체 파일 시스템을 재구성하지 않고) 더 추가하는 것은 불가능합니다. 정전 중에 작성 중인 inode 블록이 손실/손상되더라도 몇 개의 inode만 손실되며 이는 파일 시스템의 많은 부분을 차지하는 것보다 훨씬 낫습니다.
보다 현대적인 디자인은 다음과 같은 것을 사용합니다.B-트리변형. btrfs, XFS 및 ZFS와 같은 최신 파일 시스템은 inode 제한이 없습니다.
답변2
많은 파일 시스템에는 동적으로 할당 가능한 inode 테이블(또는 이에 상응하는 윤리적 테이블)이 있습니다(XFS, BTRFS, ZFS, VxFS...).
원래 Unix UFS에는 파일 시스템이 생성될 때 고정된 inode가 있었지만, 여기에서 파생된 파일 시스템(Linux EXT, Solaris UFS)은 일반적으로 이 체계를 계속합니다. 강력하고 구현하기 쉽습니다. 너무 많은 사용 사례가 있기 때문에 단지 한 가지 문제를 피하기 위해 새로운 파일 시스템을 설계하는 것은 정당화하기 쉽지 않습니다.
답변3
일부 파일 시스템은 inode를 동적으로 할당할 수 있습니다. 제 생각에는 최소한 Veritas VxFS(= HP-UX의 기본 파일 시스템, Solaris에서 사용할 수 있는 선택 사항 중 하나) 및 XFS(RHEL 7의 표준 파일 시스템 유형)는 그런 식으로 작동합니다. . Btrfs와 IBM의 JFS도 마찬가지입니다.