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