디스크에 몇 번이나 액세스되었습니까?

배경

다음과 같은 디렉터리 설정이 있다고 가정합니다.

$ ll
total 0
-rw-r--r-- 2 root root 0 Jul 29 23:36 afile.txt
-rw-r--r-- 2 root root 0 Jul 29 23:36 hL
lrwxrwxrwx 1 root root 9 Jul 30 01:22 sL -> afile.txt

이제 2가지 질문을 살펴보겠습니다.

---

질문

1. 위 파일의 inode를 가리키는 하드링크 /hL이 주어진다면, 디스크 접근 순서는 무엇인가?

하드 링크를 사용하면 가리키는 원본 파일/디렉토리와 동일한 inode 참조를 갖습니다. 따라서 이를 읽기 위한 추가 HDD 액세스가 없습니다.

예를 들어:

$ stat hL | head -3
  File: ‘hL’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d    Inode: 667668      Links: 2

그리고

$ stat afile.txt | head -3
  File: ‘afile.txt’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d    Inode: 667668      Links: 2

이 둘의 유일한 차이점은 이름입니다. 따라서 두 경로 모두 HDD 액세스 횟수가 동일합니다.

2. 위 파일을 가리키는 소프트 링크 /sL이 주어진다면, 디스크 접근 순서는 무엇인가?

그러나 소프트 링크를 통해 추가적인 HDD 접근이 가능합니다. 이러한 추가 액세스는 파일이 있는 디렉토리의 메타데이터에 대한 것입니다 sL. 그러면 파일이 실제로 심볼릭 링크이고 다른 파일/디렉토리를 가리킨다는 세부 정보가 반환됩니다.

예를 들어:

$ stat sL | head -3
  File: ‘sL’ -> ‘afile.txt’
  Size: 9           Blocks: 0          IO Block: 4096   symbolic link
Device: fd00h/64768d    Inode: 681295      Links: 1

여기서는 해당 유형이 "Symbolic Link"이고 afile.txt.

그럼 읽는 순서는 어떻게 되나요?

Bash 셸 자체를 사용하여 이러한 파일/디렉터리에 대해 명령을 실행하면 strace어떻게 작동하는지 확인할 수 있습니다 .

[pid 18098] stat("/tmp/adir/hL", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 18098] open("/tmp/adir/hL", O_RDONLY) = 3
[pid 18098] fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0

이는 명령의 출력입니다 more /tmp/adir/hL.

을 위한 /tmp/adir/hL:

• 통계/오픈(/) → 통계/오픈(tmp) → 통계/오픈(adir) → 통계/오픈(hL)

을 위한 /tmp/adir/sL:

• 통계/오픈(/) → 통계/오픈(tmp) → 통계/오픈(adir) → 통계/오픈(sL) → 통계/오픈(afile.txt)

자세한 내용은

이것심볼릭 링크에 대한 Wikipedia 페이지또한 이 모든 것을 피하십시오:

inode 내에 링크 값을 저장하면 디스크 블록과 디스크 읽기가 저장되지만 운영 체제는 여전히 링크의 경로 이름을 확인해야 합니다. 이를 위해서는 항상 추가 inode를 읽어야 하며 일반적으로 다른(아마도 많은) 디렉토리를 읽고 목록을 처리해야 합니다. 링크의 경로 구성 요소와 일치하는 항목이 발견될 때까지 파일 및 각 파일의 inode를 검색합니다. 빠른 기호 링크는 링크가 동일한 디렉터리에 있는 파일을 가리키는 경우에만 다른 기호 링크보다 훨씬 더 나은 성능을 제공합니다.

인용하다

• 심볼릭 링크 - Wikipedia

두 질문은 실제로 "어떻게 작동하나요?"라는 동일한 질문 path_resolution이므로 이 관점에서 전체 프로세스를 살펴보세요.

~에서경로 해상도(7)우리는 읽고:

파일 이름(또는 경로 이름)은 다음과 같이 구문 분석됩니다.

그런 다음 첫 번째 단계가 하드 링크와 기호 링크 모두에 공통적이라는 것을 알 수 있습니다(시스템은 경로 확인을 위한 시작점을 결정합니다: 루트 디렉터리 /, chroot된 디렉터리 또는 현재 디렉터리).

경로 이름이 "/" 문자로 시작하는 경우 찾을 시작 디렉터리는 호출 프로세스의 루트 디렉터리입니다. (프로세스는 상위 프로세스로부터 루트 디렉토리를 상속받습니다. 일반적으로 이는 파일 계층의 루트 디렉토리가 됩니다. 프로세스는 chroot(2) 시스템 호출을 사용하여 다른 루트 디렉토리를 얻을 수 있습니다. 프로세스는 완전히 비공개 마운트를 얻을 수 있습니다. 경로 이름의 "/" 부분을 처리하는 CLONE_NEWNS 플래그 세트와 함께 Clone(2) 시스템 호출을 호출하여 이름 공간(또는 그 조상 중 하나)이 시작되는 경우 네임스페이스.

경로 이름이 "/" 문자로 시작하지 않는 경우 구문 분석 프로세스의 시작 디렉터리는 프로세스의 현재 작업 디렉터리입니다. (이 역시 부모로부터 상속됩니다. chdir(2) 시스템 호출을 사용하여 변경할 수 있습니다.)

"/" 문자로 시작하는 경로 이름은 절대 경로 이름입니다. "/"로 시작하지 않는 경로 이름은 상대 경로 이름입니다.

보시다시피 하드 링크와 심볼릭 링크의 시작점에는 차이가 없습니다. 그러나 길을 걷기 시작할 때 다음 단계는 차이를 만듭니다.

현재 검색 디렉터리를 검색 시작 디렉터리로 설정합니다. 이제 경로 이름의 최종이 아닌 각 구성 요소(여기서 구성 요소는 "/" 문자로 구분된 하위 문자열임)에 대해 해당 구성 요소는 현재 조회 디렉터리에서 검색됩니다.

프로세스에 현재 검색 중인 디렉터리에 대한 검색 권한이 없으면 EACCES 오류("권한 거부")가 반환됩니다.

구성 요소를 찾을 수 없으면 ENOENT 오류("해당 파일이나 디렉터리가 없습니다")가 반환됩니다. 구성 요소가 발견되었지만 디렉토리나 심볼릭 링크가 아닌 경우 ENOTDIR 오류("디렉토리가 아님")가 반환됩니다.

구성 요소가 발견되고 디렉터리인 경우 현재 검색 디렉터리를 해당 디렉터리로 설정하고 다음 구성 요소로 이동합니다.

설명에서 볼 수 있듯이 파일과 하드 링크의 경로 확인에는 차이가 없습니다. 프로세스는 동일합니다. 심볼릭 링크는 어떻습니까? 추가 자료:

구성 요소가 발견되고 그것이 기호 링크(symlink)인 경우 먼저 기호 링크를 확인합니다(현재 검색 디렉터리를 시작 검색 디렉터리로 사용). 오류가 발생하면 이 오류가 반환됩니다. 결과가 디렉터리가 아니면 ENOTDIR 오류가 반환됩니다. 심볼릭 링크가 성공적으로 확인되고 디렉터리를 반환하면 현재 조회 디렉터리를 해당 디렉터리로 설정하고 다음 구성 요소로 이동합니다. 경로 이름의 접두사("dirname") 구성 요소에 파일 이름이 포함된 경우 해당 파일 이름은 디렉터리에 대한 심볼릭 링크로 확인됩니다(디렉토리의 접두사 구성 요소에 심볼릭 링크가 포함될 수 있으므로 여기서 확인 프로세스에는 재귀가 포함될 수 있음). 존재하다). 스택 오버플로로부터 커널을 보호하고 서비스 거부를 방지하기 위해 최대 재귀 깊이와 따라오는 최대 심볼릭 링크 수에 제한이 있습니다. 최대값을 초과하면 ELOOP 오류("심볼릭 링크 수준이 너무 많습니다")가 반환됩니다.

위에서 언급한 것처럼 심볼릭 링크 확인에는 추가 디스크 액세스 작업이 필요하므로 다음 두 질문에 대답하십시오.

위 파일의 inode를 가리키는 하드링크 /hL이 주어진다면, 디스크 접근 순서는 무엇인가?

그리고

위 파일을 가리키는 소프트 링크 /sL이 주어진다면, 디스크 접근 순서는 무엇인가?

하드 링크 액세스는 일반 파일 액세스와 다르지 않지만 기호 링크 해결에는 추가 디스크 액세스 작업이 필요하다는 결론을 내릴 수 있습니다.심볼릭 링크 해결.

추가 자료:

• 경로 해상도(7)
• 오픈(2)
• 링크(2)
• 심볼릭 링크(2)
• 통계(2)