inode에서 간접 포인터를 사용하면 동일한 양의 공간이 생성되지 않는 이유는 무엇입니까?

inode 수준의 원래 계층 구조는 대략 다음과 같습니다.

하나 또는 여러 개의 블록 번호를 inode에 직접 저장할 수 있습니다. 즉, inode에 몇 바이트를 더 사용하지만 작은 파일의 경우 대부분 비어 있는 전체 블록을 할당할 필요가 없습니다.

다음 단계는 간접 주소 지정입니다. 즉, 블록 포인터를 저장할 블록을 할당합니다. 이 간접 블록의 주소만 inode에 저장됩니다. 이것은 어떻게든 "적은 공간"을 사용하지 않으며 대부분의 파일 시스템, 심지어 초기 시스템도 이와 같이 작동합니다(inode/파일 이름 근처에 block을 가리키는 포인터가 있고 블록은 파일의 블록 번호를 저장합니다).

하지만 이 블록에 공간이 부족하면 어떻게 합니까? 다른 블록을 할당해야 하는데 이 블록에 대한 참조를 어디에 저장합니까? 이러한 참조를 inode에 추가하면 되지만 더 큰 파일을 저장하려면 inode가 더 커집니다. 그리고 가능한 한 많은 inode가 단일 블록에 들어갈 수 있도록 더 작은 inode를 원합니다(더 적은 수의 inode를 읽기 위해 더 적은 디스크 액세스).

따라서 2단계 간접 블록을 사용합니다.하나inode에 대한 포인터가 있으면 파일 자체의 블록 주소를 저장하는 간접 블록에 대한 포인터를 저장하는 완전한 블록이 있습니다.

그리고 더 높은 수준의 간접 블록을 추가하거나 원하는 구조의 파일이 가능한 최대 크기에 도달할 때까지 특정 단계에서 중지할 수 있습니다.

따라서 요점은 "전체적으로 더 적은 공간을 사용하는 것"이 ​​아니라 "예상되는 파일 크기 분포(즉, 많은 작은 파일, 일부 큰 파일 및 소수의 큰 파일)를 달성하기 위해 블록을 효율적으로 사용하는 구성표를 사용하는 것"입니다.

반면에 페이지 테이블은 상당히 다르게 작동합니다.

편집하다

댓글의 질문에 답해 주세요.

데이터 블록은 기본 하드 디스크 블록 크기의 배수인 고정 크기(원래 512바이트, IIRC)를 갖습니다. 따라서 데이터 블록 크기를 "줄일" 수 없습니다.

위에서 설명하려고 시도한 것처럼 inode가 너무 많은 공간을 차지하지 않도록 하는 전체 목적은 다음과 같습니다.인덱스 노드 액세스가 더 빠릅니다.(또는 캐시된 inode가 더 적은 메모리를 차지합니다. inode가 있는 유닉스 파일 시스템이 발명되었을 당시 컴퓨터에는많은오늘보다 메모리가 적습니다.) 그것은아니요어떻게 든 전체 공간을 절약하는 방법. 스스로 말했듯이 모든 것은 어딘가에 저장되어야 하며 위치 X의 공간을 사용하지 않으면 위치 Y의 공간을 사용하게 됩니다.

단순히 inode에 가변 개수의 블록 포인터를 추가하는 것은 inode가 고정된 공간을 차지해야 하기 때문에 비실용적입니다. inode 번호를 사용하여 inode 정보가 저장된 블록 내 블록 주소와 오프셋을 계산합니다. 각 inode의 크기가 다른 경우에는 이 작업을 수행할 수 없습니다. 그래서 있어야합니다일부간접적인 형태.

페이지 테이블은 하드웨어가 페이지 테이블을 다르게 구현하기 때문에 다르게 작동합니다. 그게 전부입니다. 계층 구조에는 항상 동일한 고정된 깊이가 있습니다(때때로 구성 가능함). 디스크에서 블록을 읽는 속도는 느리지만 페이지 테이블에서는 중요하지 않습니다. 따라서 디자인 문제는 완전히 다릅니다.