나는 왜 우리에게 inode가 필요한지 정말로 이해하지 못합니다. 매뉴얼을 검색한 후, 매뉴얼이 파일이나 디렉토리에 대한 일부 메타데이터를 저장한다는 것을 알게 되었습니다. 그런데 그게 이미 디렉토리의 역할이 아니던가? (크기, 이름 등을 보유하는 파일 항목을 저장합니다.)
답변1
바로 구현 방식입니다.
일부 디렉터리에 대해 모드를 설정해 보세요.
읽을 수 있지만 인터리브되지 않도록 설정: ug=r. 파일 이름은 표시되지만 모드, 파일 크기 등은 표시되지 않습니다.
인터리브 처리하되 읽을 수 없도록 만드세요: ug=x. 이름은 볼 수 없지만 이름을 알면 모드, 파일 크기 등을 알 수 있습니다.
왜
메타데이터를 디렉터리 구조 외부에 유지하면(즉, 이름만) 속도가 더 빨라질 수 있습니다. 필요하지 않은 많은 양의 데이터를 처리할 필요가 없습니다. 그러면 필요할 때 읽을 수 있습니다.
각 inode는 0개 이상의 이름을 가질 수 있습니다(아마도 다른 디렉토리에 있음). 해당 이름을 제거하면 파일 이름은 0이 되지만 해당 파일은 프로세스에 의해 계속 열려 있습니다. 이름이 여러 개 있을 수도 있습니다.
이름을 바꾸는 것이 더 쉬워집니다. inode에 대한 새 디렉토리 항목(이름)을 생성하고(아마도 다른 디렉토리에) 이전 디렉토리 항목(이름)을 삭제합니다.
이전 파일 시스템에서는 디렉토리에 ..상위 디렉토리의 inode를 가리키는 항목이 있었습니다. 이렇게 하려면 단일 파일에 여러 이름을 허용하는 것이 중요합니다(디렉토리는 파일 형식임). 인덱스 노드를 복제하지 않는 것은 좋은 일입니다(불일치가 발생하지 않고 낭비가 적습니다). 최신 파일 시스템(예: ext3, ext4)에서는 이것이 (내가 아는 한) 에뮬레이트됩니다.
답변2
"인덱스 노드", Wikipedia:
각 inode는 속성을 저장합니다.및 디스크 블록 위치객체 데이터
(크기가 아니라 위치가 중요함)
디렉토리는 inode에 할당된 이름 목록입니다.. 디렉토리에는 자체, 상위 디렉토리 및 각 하위 디렉토리에 대한 항목이 포함되어 있습니다.
개체가 일반 파일인 경우 리프이며 데이터만 포함합니다. 디렉토리의 데이터는다른목록 등을 포함하는 추가 디렉토리를 포함한 파일 목록.
이 모든 것에는 실용적인 측면(공간, 속도, 견고성)이 있습니다. ReiserFS에는 명시적인 inode가 없는 것 같습니다.
일부 Unix 스타일 파일 시스템(예: ReiserFS)은 inode 테이블을 생략하지만 동등한 데이터를 저장해야 합니다.동등한 기능을 제공합니다. 데이터통계라고 할 수 있다, 프로그램에 데이터를 제공하는 stat 시스템 호출을 참조하세요.
설명하기 위해 단락을 작성했습니다. /sys에서 실행했습니다. Sysfs의 최상위 inode는 "1"입니다(proc과 마찬가지로 -설치됨; "/"에는 "2"가 있으며 ls -a DOT에서는 "2.."로 표시됩니다.
for dir in . block bus; do echo -n "---[$dir]"; command ls -ali $dir | sed -E 's/( *\w ).*( \w*)/\1\2/' |head -5; done |sed "s/total .*/---/"
여기에는 디렉터리와 두 개의 하위 디렉터리에 있는 처음 4개 항목이 나열되어 있으며 inode와 이름만 표시됩니다( ls -ali첫 번째 필드와 마지막 필드만 표시됨).
---[.]---
1 .
2 ..
3321 block
8 bus
---[block]---
3321 .
1 ..
62233 ../devices/virtual/block/loop0
62347 ../devices/virtual/block/loop1
---[bus]---
8 .
1 ..
25390 ac97
3573 acpi
name예를 들어 id일반 데이터베이스 테이블의 경우 및parent_id이는 다음과 같습니다.
"/" 2 2
sys 1 2
bus 8 1
block 3321 1
ac97 25390 8
파일(또는 항목) "ac97"에는 parentid=8이 있습니다. 따라서 "버스"에 속합니다. (저는 손가락으로 했어요)
기술적으로, 동일한 디렉토리(parentid)에 있는 두 번째 "ac97"도 고유한 ID를 얻는 한 괜찮습니다. 이것은 하드 링크의 반대입니다. 경로 이름이 충분하지 않으므로 /sys/bus/ac97 with inode xy아무도 원하지 않으므로 "파일이 존재합니다"라는 메시지가 표시되거나 man 2 mkdir잘 설명됩니다.
EEXIST pathname already exists (not necessarily as a directory).
This includes the case where pathname is a symbolic link, dangling or not
...왜냐하면 데드 링크에도 디렉토리가 있기 때문입니다.
파일과 마찬가지로 디렉터리도 여러 블록에서 확장될 수 있어야 합니다. 계층 구조는 사용자를 위해 데이터를 나눕니다.그리고체계. 파일 이름은 사용자가 사용하기 위한 것입니다. 시스템의 inode(inode 번호)입니다. 하드 링크는 사용자가 파일 이름뿐만 아니라 실제 파일을 처리하는 방법입니다.
Inode는 사용자 디렉터리 구조와 블록의 파일 시스템 데이터 사이를 연결하는 역할을 합니다.
고전적인 의미("인덱스" 오프셋/아웃소싱 메타데이터)에서는 필요하지 않습니다.
"파일 시스템 트리" 아래의 "btrfs" 기사에는 다음이 있습니다.
각 디렉터리에서 디렉터리 항목은 [이 오른쪽 키 값]이 [해당 CRC32C 해시 값]인 디렉터리 항목으로 나타납니다. 파일 이름. 그들의 데이터는장소열쇠, 또는인덱스 노드 항목포인트합니다. 따라서 디렉토리 항목은 함께 inode 경로 조회를 위한 색인 역할을 할 수 있습니다.
기사 트리, 첫 번째 명확성:
트리 데이터 구조를 정의할 수 있습니다.재귀적으로로서노드 수집(루트 노드에서 시작), 각 노드는 값으로 구성된 데이터 구조입니다.노드에 대한 참조 목록 ("자식"), 중복된 참조가 없고 루트를 가리키는 것도 없다는 제약 조건이 적용됩니다.
누구세요아니요NODE 앞의 "i"가 무엇을 의미하는지 물어보세요. 누구세요?
기사 "연결된 목록", "검색 속도 향상"
또 다른 일반적인 접근 방식은"색인"보다 효율적인 연결 목록 사용외부 데이터 구조. 예를 들어, 레드 블랙 트리또는 요소가 연결된 목록에 대한 참조인 해시 테이블마디. 이러한 여러 인덱스는 단일 목록에 구축될 수 있습니다. 단점은 노드가 추가되거나 제거될 때마다(또는 적어도 인덱스가 다시 사용되기 전에) 이러한 인덱스를 업데이트해야 할 수도 있다는 것입니다.
"i"가 "inode"에서 많은 것을 나타내지 않고 단지 "index"만 나타내는 것은 당연합니다.