나는 현재 W. Richard Stevens가 쓴 "Advanced UNIX 프로그래밍"이라는 책을 읽고 있는데, 그 책에서 UNIX의 모든 파일에는 번호가 있고 파일 이름은 단지 사용자 편의를 위해 만들어졌다는 내용을 읽었습니다. 디렉토리를 입력한 후 시스템은 입력된 이름에 대한 번호를 검색합니다.
나는 속으로 생각했다. 그들이 이 번호를 어떻게 확인할 것인가? 저장된 파일은 이진 검색으로 찾을 수 있도록 이름별로 정렬되어 있습니까? 아니면 목록 끝에 새 파일을 추가합니까?
답변1
다양한 파일 시스템 형식, 다양한 시나리오에서의 성능(큰 디렉터리 대 작은 디렉터리, 읽기 대 쓰기, 동시 액세스 등), 설계 단순성(오류 가능성, 개발 노력 등), 디스크 오버헤드가 다릅니다. 파일 콘텐츠 이외의 항목에 대한 (공간) 등 간에 절충이 이루어집니다.
이전 파일 시스템(예:UFS, FFS,외부 2, 원래외부 3,...)는 디렉토리를 항목 배열(각 항목에는 파일 이름, inode 번호 및 일부 추가 메타데이터가 포함됨)로 저장하고 선형 검색을 수행하는 것을 선호합니다. 새 파일은 배열의 첫 번째 여유 항목에 추가됩니다. 여유 항목이 없으면 배열이 먼저 확장됩니다. 이로 인해 대규모 디렉터리의 성능이 저하될 수 있습니다.
최신 파일 시스템(예:외부 3옵션 으로 dir_index,외부 4,지브스,BTFS,레이셀프스,고주파 FS,고주파 FS+,...) 로그 시간 조회, 일종의 균형 검색 트리, 해시 테이블 또는 둘의 조합(해시 균형 검색 트리)을 사용하여 디렉토리를 데이터 구조로 저장하는 경향이 있습니다.B-트리. 이는 파일 시스템 코드를 더 복잡하게 만들지 만 큰 디렉터리에서 좋은 성능을 유지합니다.
답변2
이 번호는인덱스 노드. Ext4는 해시 트리를 사용하는 가장 널리 사용되는 Linux 파일 시스템 유형 중 하나입니다.kernel.org - Ext4 디스크 레이아웃.
해시 트리에 대한 자세한 내용은 다음을 참조하세요.위키피디아.
답변3
파일 시스템에 따라 다릅니다. 오래 전에 Unix 디렉토리는 본질적으로 16바이트 레코드(내부 번호 2바이트, 파일 이름 14바이트)로 구성된 파일이었습니다. 이것이 파일 이름에 대한 기존의 14자 제한이 있는 이유입니다. 레코드가 정렬되지 않으므로 파일에 대한 선형 검색이 필요합니다.
보다 현대적인 파일 시스템(예: Linux의 Ext4)에는 검색 속도를 높이기 위한 해시 테이블이 있습니다.
답변4
현학적 경고: 설명이 불완전합니다. 파일 이름은 사용자에게 편리하다고만 설명할 수 없습니다. 파일명이 다음과 같은 것으로 확인되었습니다.극도로UNIX 기반 시스템에서 중요합니다.
inode 번호는 파일 시스템 모듈에 의해 선택되므로 의미가 없습니다. 처음에는 디스크에 저장된 inode 테이블의 슬롯을 식별합니다. 시스템의 다른 부분은 /dev/tty1또는 와 같은 특정 의미를 가진 파일에 액세스해야 합니다 /etc/passwd.
특정 단어를 사용하지 않고도 명령 선택(예: 이름별) cat을 위한 사용자 인터페이스를 제공하는 데 사용되는 메커니즘을 설명하기에는 "편의성"이 너무 하찮습니다.ed
파일 이름 디렉토리가 없으면 이러한 용도를 지원하기 위해 inode 번호에 대해 매우 유사한 이름 레지스트리를 빨리 만들어야 합니다.
디렉토리 항목에는 특별한 의미 .도 있습니다. ..가상 파일 시스템은 예를 들어 프로세스 1에 대한 정보를 제공하기 proc위해 파일 이름을 사용합니다 . /proc/1/commVFS는 또한 유닉스 기반일 필요가 없고 동일한 inode 번호 개념을 사용하지 않을 수 있는 다양한 파일 시스템의 사용을 허용합니다.
ZFS는 파일 이름과 inode 메타데이터(예: 권한)가 별도의 레이어에 속한다고 생각하는 것 같습니다. 나는 이것의 이점이 무엇인지 아직 이해하지 못합니다. 중첩된 파일 시스템을 저장하는 데 사용될 때 해당 파일에 대해 다양한 성능 손잡이를 제공하는 방법에 더 가깝습니다.
또한 사용자는 일반적으로 inode 번호로 파일을 열 수 없습니다. 가능하다면 Director{y,ies}가 포함된 권한을 통해 파일에 대한 액세스를 제어할 수 없습니다...
아마도 마지막 요점을 살펴보는 또 다른 방법은 그것이 디렉토리의 속성이라는 것입니다. 디렉토리의 전체 원칙은 파일 이름을 매핑하는 것이므로 이것이 없으면 아무런 효과가 없습니다.
잠깐만요, 파일 참조용 컨테이너(예: "하드 링크") 역할을 계속할 수 있다고 말씀하셨죠. 여러 디렉터리에 있는 파일을 나열할 수 있습니다. 한 디렉터리( )에서 파일을 삭제해도 해당 파일이 다른 디렉터리에 남아 있으면 unlink실제로는 삭제되지 않습니다 . 하드 링크는 유닉스 구현의 흥미로운 부분이지만 내가 아는 한 실제로 어떤 유틸리티도 찾지 못했습니다! 그들은 종종 혼란의 기회로 간주됩니다. 이는 기능이 필요한지 여부를 실제로 생각하지 않고도 흥미로운 기능을 제공하기가 매우 쉽기 때문에 구현 세부 정보를 노출하는 예입니다. 이 특정 설계 결함은 그다지 위험하지는 않지만 "십억 달러 실수"와 유사합니다.
즉, 디렉터리가 포함된 파일의 존재를 보장하는 방식에 주목할 가치가 있습니다. 파일 식별을 위해 다른 시스템을 구현하려면 파일을 삭제하면 존재하지 않는 파일을 참조하는 항목이 남거나 동일한 inode가 할당된 관련 없는 새 파일이 남을 수 있다는 점을 고려해야 합니다. 나중에 번호를 매겼습니다.