나는 디렉토리가 "name = inode number" 줄을 포함하는 파일이라는 것을 이해합니다.
/home/my_file.txt와 같은 경로를 요청하면 다음 단계가 수행됩니다.
- inode 번호 2로 이동(루트 디렉터리 기본 inode)
- inode #2가 가리키는 파일을 가져옵니다.
- 파일을 검색하고 "home" 항목을 찾으세요. 해당 inode 번호(예: 135)를 가져옵니다.
- inode #135가 가리키는 파일을 가져옵니다.
- 파일을 검색하고 "my_file.txt" 항목을 찾으세요. 해당 inode 번호(예: 245)를 가져옵니다.
- inode #245가 가리키는 파일을 가져옵니다.
질문:홈 디렉토리가 다른 블록 장치에 있는 다른 파일 시스템의 마운트 지점인 경우 프로세스는 어떻게 다릅니까? 시스템이 이 디렉토리가 마운트 지점이라는 것을 알게 되면 어떻게 합니까? 이 정보는 어디에 저장되어 있습니까? inode, 디렉터리 파일, 아니면 다른 곳입니까?
예를 들어 내 루트 디렉터리 목록의 일부에는 inode 번호가 표시됩니다.
ls -d1i /*/
inode # name
656641 /bin/
2 /boot/
530217 /cdrom/
2 /dev/
525313 /etc/
2 /home/
393985 /lib/
여기서 홈 및 부팅 디렉터리는 마운트 지점이며 자체 파일 시스템에 있습니다. 위에 작성된 의사코드 알고리즘을 실행하고 3단계에서 멈춥니다. 이 경우 기본 inode 번호는 2이며 다른 파일 시스템과 다른 블록 장치에 있습니다.
답변1
프로세스에 대한 설명이 올바르지 않습니다.
커널은 어떤 경로가 마운트 지점인지 추적합니다. 이것이 수행되는 정확한 방법은 커널마다 다르지만 일반적으로 정보는 경로 형식으로 저장됩니다. 예를 들어, 커널은 " /이 파일 시스템이야, /media/cdrom이게 파일 시스템이야, /proc이건 이 파일 시스템이야" 등을 기억할 것입니다. 일반적으로 커널은 마운트된 파일 시스템의 데이터 구조를 나타내는 테이블에 경로 문자열을 매핑하는 대신 각 디렉터리에 대한 테이블을 저장합니다. 디렉토리 항목과 관련된 데이터를 종종디렉토리 항목. 루트 디렉토리에 대한 디렉토리 항목이 있으며, 각 디렉토리에서 커널은 해당 디렉토리에 있는 각 파일에 대한 디렉토리 항목을 기억합니다. dentry에는 inode 구조에 대한 포인터가 포함되어 있고 inode에는 파일이 있는 파일 시스템의 파일 시스템 데이터 구조에 대한 포인터가 포함되어 있습니다. 마운트 지점에서 연관된 파일 시스템은 상위 디렉토리 항목의 파일 시스템과 다르며 마운트 지점을 추적하기 위한 추가 메타데이터가 있습니다. 따라서 일반적인 유닉스 커널 아키텍처에서 dentry에는 /루트 디렉터리의 inode 포인터 외에도 루트 파일 시스템 정보에 대한 포인터가 포함되어 있습니다 /proc(마운트 지점이라고 가정). proc 파일에 대한 정보에 대한 포인터가 포함되어 있습니다. 시스템 등 포인터. /media/cdrom마운트 지점이지만 그렇지 않은 경우 /media커널은 이를 dentry에 기억 /media하고 잊어버리는 것이 허용되지 않습니다. /media단순히 성능을 위한 캐싱의 문제가 아니라 마운트 지점의 존재를 기억해야 합니다 /media/cdrom.
Linux의 경우 다음에서 문서를 찾을 수 있습니다.커널 문서,이 웹사이트에서그리고 웹의 다른 곳에서도요.브루스 필즈주제에 대한 좋은 소개입니다.
커널이 파일에 액세스하라는 명령을 받으면 파일 이름을 한 번에 슬래시로 구분된 구성 요소 하나씩 처리하여 매번 해당 구성 요소를 찾습니다. 심볼릭 링크를 찾으면 이를 따릅니다. 마운트 지점을 찾으면 실제로 특별한 처리가 필요하지 않습니다. inode를 다른 디렉토리에 추가하기만 하면 됩니다.
이 프로세스는 다음과 같이 inode 번호를 사용하지 않습니다.바늘. Inode 번호는 디스크와 애플리케이션 모두에서 커널 외부의 지정된 파일 시스템에 있는 각 파일에 대한 고유 ID를 제공하는 방법입니다. 일부 파일 시스템에는 고유한 inode 번호가 없습니다. 파일 시스템 드라이버는 종종 이를 구성하려고 시도하지만 항상 작동하지는 않습니다. 특히 네트워크 파일 시스템의 경우(예를 들어 서버가 그 위에 마운트 지점이 포함된 디렉토리 트리를 내보내는 경우) mount 아래의 inode 세트 사이에 겹침이 있을 수 있습니다. 이름을 inode 번호에 매핑하는 행은 일반적인 디스크 파일 시스템이 작동하는 방식입니다(하드 링크를 지원하는 경우). 실제로는 inode 번호 개념이 필요하지 않습니다.
마운트 지점에 대한 정보는 메모리에만 저장됩니다. 파일 시스템을 마운트할 때 파일 시스템이 마운트된 디렉터리는 수정되지 않습니다. 이 디렉토리는 마운트된 파일 시스템의 루트에만 숨겨져 있습니다.
답변2
구현 문제이기 때문에 보편적으로 대답할 수 있을지 모르겠습니다. 물론 운영 체제는 주어진 디렉터리가 마운트 지점이라는 것을 어떻게든 알아야 하지만 운영 체제 작성자는 이것이 어떻게 달성되는지 생각해야 합니다. 나는 Linux, *BSD, Solaris 등의 내부 구조를 알지 못하며 그들 사이에 어떤 유사점이나 차이점이 있다고 감히 가정하지도 않습니다.
추측으로는 {device, inode} 쌍(st_dev그리고st_inostruct stat). 디렉토리에 대한 하드 링크가 비활성화되어 있다고 가정하면 디렉토리 inode도 고유한 이름을 갖게 됩니다.
따라서 한 가지 접근 방식은 시스템의 모든 마운트 지점에 대한 테이블을 만든 다음 운영 체제가 경로를 탐색할 때 각 디렉터리를 확인하는 것입니다.
시스템에 일종의 inode 캐시(유용한 최적화)가 있는 경우 다음과 같이 할 수 있습니다.기억 속에inode 구조를 사용하여 inode가 마운트 지점인지 확인합니다.
답변3
파일 시스템이 특정 마운트 지점에 마운트되면 운영 체제는 마운트된 파일 시스템에서 슈퍼블록을 읽어 메모리에 로드합니다. 슈퍼블록에는 무엇보다도 해당 파일 시스템 루트의 inode에 대한 정보가 포함되어 있습니다.
위의 요점은 정확합니다. 운영 체제 데이터 구조는 마운트된 모든 파일 시스템의 기록을 보유하며, 다른 파일 시스템이 /home/에 마운트된 경우 해당 파일 시스템의 슈퍼블록을 쿼리하여 루트 디렉터리의 inode 번호를 얻습니다.