왜 inode 테이블의 크기를 조정할 수 없습니까?

유닉스 파일 시스템에는 보통 inode 테이블이 있으며이 테이블의 항목 수는 일반적으로 파일 시스템이 생성 될 때 고정됩니다. 이로 인해 충분한 여유 공간이없는 디스크 공간을 가진 사람들이 사용 가능한 공간이 없다는 혼란스러운 오류 메시지를 보게되며 문제가 무엇인지 파악한 후에도 해결 방법이 없습니다.

그러나 주문형 inode를 사용자와 시스템 관리자에게 완전히 투명하게 할당하여 이러한 혼란을 피하는 것이 매우 바람직 할 것 같습니다. 귀여운 해킹에 빠지면 inode 테이블 자체를 파일로 만들 수 있으므로 디스크의 여유 공간을 찾는 기존 코드를 재사용 할 수 있습니다. 운이 좋으면 명시 적 으로이 결과를 얻으려고하지 않고 파일 자체 근처의 inode로 끝날 수도 있습니다.

그러나 아무도 (내가 아는) 실제로 이것을하지 않으므로 아마도 내가 놓친 캐치가있을 것입니다. 그게 뭔지 알아?

inode 테이블을 파일로 만들었습니다. 다음 질문은 ... 해당 파일에 대한 정보를 어디에 저장합니까? 따라서 MS-DOS 파티션 테이블과 같이 "실제"inode와 "확장"inode가 필요합니다. 주어진 것만으로도 하나만 필요합니다 (예 : 저널을 파일로 만들려면 몇 개). 그러나 실제로는 특별한 경우, 다른 코드가 있습니다. 해당 파일이 손상되면 치명적일 수 있습니다. 또한 저널링 전에 전원이 크게 손상되었을 때와 같이 쓰여지는 파일이 일반적이라고 생각하십시오. 귀하의 파일 작업이 될 것이다 많은 등보다 강력한 대 정전 / 사고 /. 예를 들어, ext2보다 그렇습니다.

전통적인 유닉스 파일 시스템은 더 단순하고 강력한 솔루션을 찾았습니다. X 블록마다 아이 노드 블록 (또는 블록 그룹)을 넣습니다. 그런 다음 간단한 산술로 찾을 수 있습니다. 물론 전체 파일 시스템을 재구성하지 않고는 더 추가 할 수 없습니다. 그리고 전원이 꺼 졌을 때 쓰던 inode 블록을 잃어 버렸거나 손상하더라도 파일 시스템의 상당 부분보다 훨씬 적은 inode 만 손실됩니다.

보다 현대적인 디자인은 B- 트리 변형 과 같은 것을 사용 합니다. btrfs, XFS 및 ZFS와 같은 최신 파일 시스템에는 inode 제한이 없습니다.

많은 파일 시스템에는 동적으로 할당 가능한 inode 테이블 (또는 그와 동등한 수준)이 있습니다 (XFS, BTRFS, ZFS, VxFS ...).

원래 Unix UFS에는 파일 시스템 작성 시간에 수정 된 inode가 있었으며 그로부터 파생 된 파일 시스템 (Linux EXT, Solaris UFS)은 종종 그 체계를 계속했습니다. 강력하고 간단하게 구현할 수 있습니다. 하나의 문제를 정당화하기가 쉽지 않다는 것을 피하기 위해 새로운 파일 시스템을 설계하는 많은 사용 사례가 적합합니다.

inode를 동적으로 할당하는 파일 시스템이 있습니다. 최소한의 Veritas VxFS (= HP-UX의 기본 파일 시스템 및 Solaris에서 사용 가능한 선택 중 하나) 및 XFS (RHEL 7의 표준 파일 시스템 유형)가 작동합니다. 그런 식으로. Btrfs와 IBM의 JFS도 마찬가지입니다.