[unix] 페이지 캐시에 100 % 페이징 된 파일이 다른 프로세스에 의해 수정 될 때 발생하는 상황

연속 릴리스는 / apps / EXE를 새로운 실행 파일로 대체합니다.

이것이 중요한 부분입니다.

새 파일을 해제하는 방법은 새 파일 (예를 만드는 것입니다 /apps/EXE.tmp.20190907080000,) 내용을 작성, 권한과 소유권을 설정하고 마지막으로 최종 이름을 보내고 (2)의 이름을 /apps/EXE이전 파일을 교체.

결과적으로 새 파일은 새로운 inode 번호를 갖게됩니다 (즉, 다른 파일임을 의미합니다).

그리고 이전 파일에는 고유 한 inode 번호가있었습니다. 실제로 는 파일 이름이 더 이상 가리 키지 않더라도 실제로 는 주변에 있습니다 (또는 더 이상 해당 inode를 가리키는 파일 이름이 없습니다).

따라서 여기서 핵심은 Linux에서 “파일”에 대해 이야기 할 때 파일이 열리면 inode가 파일에 대한 참조이므로 “inodes”에 대해 가장 자주 이야기하는 것입니다.

가정 1 : 프로세스 P (및 이전 실행 파일을 참조하는 파일 설명자가있는 다른 사람)는 문제없이 메모리 / apps / EXE에서 이전을 계속 사용하고 해당 경로를 실행하려고하는 새로운 프로세스는 새로운 실행 파일

옳은.

가정 2 : 파일의 모든 페이지가 메모리에 매핑되지 않는 경우 교체 된 파일의 페이지를 요구하는 페이지 오류가 발생할 때까지 문제가 없으며 아마도 segfault가 발생한다고 가정합니다.

맞지 않습니다. 이전 inode는 여전히 존재하므로 이전 바이너리를 사용하는 프로세스의 페이지 결함은 여전히 ​​디스크에서 해당 페이지를 찾을 수 있습니다.

이전 바이너리를 실행하는 프로세스 에 대한 /proc/${pid}/exe심볼릭 링크 (또는 동등한 lsof출력)를 보면이 효과 /app/EXE (deleted)가 나타납니다.이 이름은 더 이상 존재하지 않지만 inode가 여전히 있음 을 나타냅니다.

바이너리가 사용하는 디스크 공간은 프로세스가 종료 된 후에 만 ​​해제된다는 것을 알 수 있습니다 (아이 노드가 열려있는 유일한 프로세스라고 가정합니다). df프로세스 종료 전과 후에 출력을 확인 하면 크기가 줄어 듭니다 당신이 더 이상 주변에 없다고 생각했던 오래된 바이너리의.

BTW, 이것은 바이너리뿐만 아니라 열린 파일을 가진 것입니다. 프로세스에서 파일을 열고 파일을 제거하면 해당 프로세스가 파일을 닫을 때까지 파일이 디스크에 보관됩니다 (또는 죽습니다). 하드 링크가 디스크의 inode를 가리키는 이름 수에 대한 카운터를 유지하는 방법과 마찬가지로, Linux 커널에서 파일 시스템 드라이버 는 메모리 에있는 해당 inode 에 대한 참조 수를 카운터로 유지 하고 실행중인 시스템의 모든 참조가 릴리스 된 후에 만 ​​디스크에서 inode를 해제합니다.

질문 1 : 파일의 모든 페이지를 vmtouch와 같은 것으로 막 으면 시나리오가 변경됩니다.

이 질문은 페이지를 잠그지 않으면 segfault가 발생한다는 잘못된 가정 2에 근거합니다. 그렇지 않습니다.

질문 2 : / apps / EXE가 원격 NFS에 있다면 차이가 있습니까? (그렇지 않다고 가정)

그것은 똑같은 방식으로 대부분의 시간 동안 작동하도록 의도 되었지만 NFS에는 “gotchas”가 있습니다.

때로는 NFS에서 여전히 열려있는 파일을 삭제하는 결과물을 볼 수 있습니다 (해당 디렉토리에 숨겨진 파일로 표시됨).

또한 NFS 서버를 재부팅 할 때 장치 번호가 “재편성”되지 않도록 NFS 내보내기에 장치 번호를 할당 할 수있는 방법이 있습니다.

그러나 주요 아이디어는 동일합니다. NFS 클라이언트 드라이버는 여전히 inode를 사용하며 inode가 계속 참조되는 동안 서버에 파일을 보관하려고합니다.

답변

cp /bin/sleep sleep; ./sleep 3600 & echo none > ./sleep
[9] 5332
bash: ./sleep: Text file busy