>

현재 W. Richard Stevens의 Advance UNIX Programming이라는 책을 읽었으며 UNIX의 모든 파일에는 숫자가 있으며 파일 이름은 사용자 편의를 위해 만들어 졌다는 것을 읽었습니다. 디렉토리를 입력하면 시스템에서 입력 한 이름을 번호로 검색합니다.

나는 나 자신을 생각했는데, 어떻게 숫자를 검색합니까? 이진 검색으로 파일을 찾을 수 있도록 파일이 이름별로 정렬되어 저장됩니까? 아니면 목록 끝에 새 파일을 추가합니까?

  • 답변 # 1

    파일 시스템 형식은 여러 가지가 있으며 각기 다른 시나리오 (대형 디렉터리 대 작은 디렉터리, 읽기 대 쓰기, 동시 액세스 등), 디자인 단순성 (버그 가능성, 개발 노력 등), 디스크 성능간에 서로 다른 절충안을 만듭니다. 오버 헤드 (파일 내용 이외의 용도로 사용 된 공간) 등

    이전 파일 시스템 (예 : UFS, FFS, ext2, 원본 ext3 등)은 디렉토리를 항목의 배열 (각 항목은 파일 이름, inode 번호 및 추가 메타 데이터를 포함)로 저장하고 선형 검색을 수행하는 경향이 있습니다. . 배열의 첫 번째 빈 항목에 새 파일이 추가됩니다. 빈 공간이 없으면 배열이 먼저 확대됩니다. 큰 디렉토리에서 성능이 저하됩니다.

    최신 파일 시스템 (예 : dir_index 를 사용하는 ext3)  옵션, ext4, zfs, btrfs, reiserfs, HFS, HFS +,…)는 디렉토리를 로그 시간 조회, 일종의 밸런스 검색 트리, 해시 테이블 또는 두 가지 조합 (밸런스 검색 트리)의 조합으로 데이터 구조로 저장하는 경향이 있습니다. of hashes) — 일반적으로 B- 트리의 일부 변형입니다. 이렇게하면 파일 시스템 코드가 더 복잡해 지지만 큰 디렉토리에서는 성능이 좋아집니다.

  • 답변 # 2

    inode라고합니다. 가장 널리 사용되는 Linux 파일 시스템 유형 중 하나 인 Ext4는 해시 트리를 사용합니다. kernel.org-Ext4 디스크 레이아웃을 참조하십시오.

    wikipedia의 해시 트리에 대한 자세한 내용

  • 답변 # 3

    파일 시스템에 따라 다릅니다. 오래 전, 유닉스 디렉토리는 본질적으로 16 바이트 레코드로 구성되는 파일이었습니다. 내부 번호는 2 바이트, 파일 이름은 14 바이트입니다. 이것이 파일 이름에 대한 이전 14 자 제한의 이유입니다. 레코드가 정렬되지 않았으므로 파일을 통한 선형 검색이 필요했습니다.

    Linux의 Ext4와 같은 최신 파일 시스템에는 검색 속도를 높이기위한 해시 테이블이 있습니다.

  • 답변 # 4

    발신자 경고 : 설명이 완료되지 않았습니다. 파일 이름은 사용자의 편의를 위해서만 설명 될 수 없습니다. 유닉스 기반 시스템에서는 파일 이름이매우중요한 것으로 판명되었습니다.

    노드 번호는 파일 시스템 모듈에 의해 선택되므로 의미가 없습니다. 원래 그들은 디스크에 저장된 inode 테이블에 슬롯을 식별했습니다. 시스템의 다른 부분은 특정 의미를 가진 파일에 액세스해야합니다. 와이즈 비즈  또는 /dev/tty1 .

    특정 단어를 붙 잡지 않고 "편의"는 메커니즘을 설명하기에는 너무 사소한 데, 이는 /etc/passwd 와 같은 명령을 선택하기 위해 사용자 인터페이스를 제공하는 데 사용됩니다.  또는 cat  이름으로.

    파일 이름의 디렉토리가 없다면, 곧 이러한 용도를 지원하기 위해 inode 번호에 대한 매우 유사한 이름의 레지스트리를 발명해야 할 것입니다.

    디렉토리 항목 ed  그리고 .  또한 특별한 의미가 있습니다. .. 와 같은 가상 파일 시스템파일 이름을 사용하여 고유 한 의미를 제공하십시오 (예 : Wyzwyz 만들기  프로세스 1에 대한 정보를 제공 할 수 있습니다. VFS는 또한 다른 파일 시스템을 사용할 수있게합니다.이 파일 시스템은 유닉스를 기반으로 할 필요가없고 동일한 개념의 inode 번호와 동일하게 작동하지 않을 수 있습니다.

    ZFS는 권한과 같은 파일 이름과 inode 메타 데이터가 별도의 계층에 속하는 것으로 생각합니다. 이것이 제공하는 이점을 아직 이해하지 못했습니다. 중첩 된 파일 시스템을 저장하는 데 사용될 때 파일과 동등한 객체에 대해 다른 성능 조절기를 제공하는 방법 인 것 같습니다.

    또한 사용자는 일반적으로 inode 번호로 파일을 열 수 없습니다. 그들이 할 수 있다면, 당신은 포함하는 감독의 허가를 통해 파일에 대한 접근을 통제 할 수 없을 것입니다 {y, ies} ...

    마지막 지점을 보는 또 다른 방법은 디렉토리의 기능이라는 것입니다. 디렉토리의 전체 원리는 파일 이름을 매핑하는 것이므로 실제로 아무런 영향을 미치지 않습니다.

    잠깐, "하드 링크"라는 파일을 참조하기위한 컨테이너로 여전히 효과가있을 것입니다. 여러 디렉토리에 파일을 나열 할 수 있습니다. 한 디렉토리에서 파일 제거 ( proc )가 여전히 다른 디렉토리에 남아 있으면 삭제하지 않습니다. 하드 링크는 유닉스 구현에서 흥미로운 부분이지만 AFAIK는 실제로 유틸리티를 찾지 못했습니다! 그들은 일반적으로 혼란의 기회로만 간주됩니다. 기능이 필요한지 여부를 실제로 고려하지 않고 흥미로운 기능을 제공하기가 매우 쉽기 때문에 구현 세부 사항을 노출하는 예입니다. 이 특정 디자인 결함은 그렇게 위험하지는 않지만 "십억 달러의 실수"와 유사합니다.

    즉, 디렉토리에 포함 된 파일의 존재를 보장하는 방법에 주목할 필요가있다. 파일을 식별하기 위해 다른 시스템을 구현하려는 경우 파일을 삭제하면 존재하지 않는 파일 또는 동일한 inode가 지정된 새롭고 관련이없는 파일을 참조하는 항목이 남을 가능성을 고려해야합니다. 나중에 번호.

    /proc/1/comm

관련 자료

  • 이전 email - pam_exec를 사용한 SSH 로그인 경고
  • 다음 linux - / dev/mem에 액세스하면 우분투가 멈춤