*nix 파일 시스템은 디스크 시작 부분(또는 고정 위치)에 inode 테이블을 유지합니다. 이는 inode를 고유하게 식별하는 정수인 inode 번호로 색인화됩니다. inode 번호를 알면 inode를 빠르게 찾을 수 있습니다. inode에는 파일의 실제 데이터가 포함된 다른 디스크 블록에 대한 포인터/주소가 포함되어 있습니다.
inode 테이블과 inode 번호를 삭제하는 다음 방법이 작동하는지 알고 싶습니다.
아직 inode가 남아있지만, 이제는 inode가 디스크의 데이터 영역에 저장되고, inode 번호를 추적하는 대신에 inode의 디스크 주소나 블록 번호만 기록하게 됩니다. 파일이나 해당 inode에 액세스하려고 할 때마다 inode 테이블을 인덱싱하기 위해 inode 번호를 사용하는 대신 디스크 주소를 사용하여 inode를 찾습니다. 이렇게 하면 또 다른 간접 계층으로부터 우리를 구할 수 있습니다.
내 접근 방식에 무엇이 빠졌습니까? inode 테이블의 근거를 이해하고 싶습니다.
답변1
내가 올바르게 이해했다면 inode 번호를 블록 주소로 바꾸고 싶을 것입니다. 이는 (1) 블록당 하나의 inode가 많은 공간을 낭비한다는 것을 의미합니다(inode는 그다지 크지 않음). (2) 이는 inode 번호 매기기를 사용하는 것과 다르지 않습니다. inode는 고정된 크기를 가지므로 블록에는 알려진 수 n의 inode가 포함됩니다. 아이노드 . 따라서 inode 번호 n(이상적으로는 2의 거듭제곱이므로 시프트)를 나누면 몫은 inode의 블록 번호(inode 테이블이 시작되는 디스크 주소 포함)이고 나머지는 inode의 인덱스입니다. 그 블록 내에서.
inode 테이블의 이론적 근거를 이해하려면 inode 테이블에 저장된 데이터를 고려하십시오. 이는 소유자, 그룹, 권한, 타임스탬프뿐 아니라 데이터 블록의 인덱스 및 간접 인덱스와 같은 속성입니다. 어딘가에 저장해야 하며, 파일 데이터와 함께 저장할 수는 없습니다.
따라서 자신만의 파일 시스템을 설계하려는 경우 대답해야 할 첫 번째 질문은 "파일에 속한 데이터 블록을 어떻게 식별합니까?"입니다. 두 번째 질문은 "소유권, 사용 권한과 같은 속성을 어디에 저장합니까?"입니다. 그리고 타임스탬프는요?" . 예, inode와 다른 구성표를 사용할 수 있습니다.
편집하다
에 관해서는
주 메모리와 그 안에 있는 객체에 사용하는 것처럼 주소를 사용하면 어떨까요?
내가 쓴 것처럼 기본적으로 이미 블록 주소가 있습니다. 먼저 이를 나누고 오프셋을 추가하면 됩니다. 원칙적으로 오프셋이 각 inode에 추가되면 "inode 번호"는 훨씬 더 커지며 각 inode 번호에서 반복되는 상위 비트에 상수 값이 있게 됩니다. 그러면 각 디렉토리 항목이 더 커집니다.
하드 드라이브 크기가 약 20MB였을 때 유닉스 파일 시스템이 발명되었다는 사실을 잊지 마십시오. 공간을 낭비하고 싶지 않으므로 모든 것을 조밀하게 포장하고 중복을 피하십시오. 인덱스 노드에 접근할 때마다 오프셋을 추가하는 비용은 낮습니다. 이 오프셋을 각 "inode 번호" 참조의 일부로 저장하는 것은 비용이 많이 듭니다.
흥미롭게도 inode 체계는 오늘날의 소형 드라이브용으로 개발되었지만 확장성이 뛰어나고 테라바이트 크기의 드라이브에서도 "작동"합니다.