그래서 NFS 서버 역할을 하는 Linux 상자가 있습니다. 내보내는 폴더에는 많은 프로그램이 설치됩니다.
다른 Linux 상자에서 내보낸 NFS 폴더에 있는 프로그램을 꽤 오랫동안 실행했는데 빨리 끝나지 않습니다.
알고 보니 네트워크에 긴급 유지 관리 작업을 해야 해서 일정 기간 동안 네트워크가 다운될 예정이었습니다.
실행 중인 프로그램이 어떻게 되는지 알고 싶습니다.
내가 이해하는 바는 프로그램이 게으른 방식으로 RAM에 로드된다는 것입니다. 따라서 최상의 시나리오에서는 프로그램이 이미 RAM에 로드된 루프의 일부인 일부 코드를 실행하고 있다고 가정하면 네트워크 중단 중에 실행 파일에 전혀 액세스할 필요가 없으며 프로그램은 정상적으로 계속 실행됩니다. , 아무 일도 없었던 것 같죠?
그러나 프로그램이 실행 파일의 다른 부분을 RAM에 로드해야 하고 네트워크가 현재 다운된 것으로 밝혀진 경우. 잠시 동안 "정지"되었다가 네트워크가 다시 작동되면 정상적인 실행을 재개합니까?
나는 이 로딩 프로세스가 결국 NFS 클라이언트 라이브러리에 의해 처리될 일부 io 관련 시스템 호출을 호출하게 된다고 생각합니다. 네트워크가 중단되면 NFS 클라이언트 라이브러리는 네트워크 중단 중에 계속 재시도한 다음 네트워크가 복원되면 성공을 반환합니다. 따라서 시스템 관점에서 볼 때 이는 오랜 시간이 걸리는 시스템 호출로 보입니다.
내 추론, 특히 로딩 프로세스 부분이 확실하지 않습니다. 실행 파일의 일부를 RAM에 로드할 때 운영 체제가 io 관련 시스템 호출을 호출합니까? 아니면 시스템 호출을 우회하고 더 낮은 수준의 메서드에서 실행한 다음 실패하여 내 프로그램의 실행이 실패하면 중지되도록 할 수 있습니까?
또한 추론을 수행할 때 NFS 캐싱 전략을 고려해야 합니까?
감사합니다~!
답변1
당신의 이해는 정확하지 않지만 가깝습니다. 프로그램이 실제로 지연 로드되었습니다.페이지페이지별로. (이들 중 일부는 실제로 사용하기 전에 로드될 수 있지만 이는 성능과 메모리의 균형이며 신뢰할 수 있는 것이 아닙니다.)
로딩을 담당하는 시스템 부분은 커널 자체입니다. 페이지는 늦어도 프로그램이 데이터에 액세스하거나 기계 명령으로 점프하기 위해 해당 메모리 블록을 필요로 할 때 로드됩니다. 작동 방식은 프로세서의 모든 메모리 액세스가 통과한다는 것입니다.메모리 관리 유닛;CPU는 요청된 액세스가 포함된 페이지가 프로세스의 MMU 테이블에 매핑된 경우에만 메모리에 액세스합니다. 페이지가 매핑되지 않은 경우 이는 트리거됩니다.덫커널에서 코드 조각을 실행하고, 트랩의 원인을 분석하고, 물리적 메모리 페이지를 할당하고, 필요한 페이지 콘텐츠를 로드하고, 제어를 프로그램에 반환하여 다시 액세스를 수행합니다.
프로그램이 메모리 페이지를 수정하면 그 내용이 다음 위치에 배치될 수 있습니다.교환그런 다음 다시 로드합니다. 메모리 페이지가 파일(실행 가능 여부에 관계없이)에서 직접 제공되면 해당 내용은 해당 파일에서 로드됩니다. 이 모든 작업은 커널 내부에서 발생하기 때문에 시스템 호출을 거치지는 않지만 파일에 액세스하는 시스템 호출과 동일한 저수준 액세스를 수행합니다.
결과적으로 실행 중인 실행 파일이 저장된 파일 시스템에 액세스할 수 없게 되면 프로세스가 중단됩니다. 그것은 남아있을 것입니다방해받지 않는 수면파일 시스템이 요청을 만족할 때까지.
실행 파일이 NFS에 있고 NFS 파일 시스템이 이 옵션을 사용하여 마운트된 경우 hard실행 파일은 영원히 기다리거나 서버가 응답할 때까지(먼저 오는 쪽 기준) 대기합니다. 이 옵션을 사용하여 NFS 파일 시스템을 마운트하면 soft시간 초과 후 NFS 요청이 실패하며 이는 프로세스에 대한 신호로 변환됩니다(SIGSEGV 또는 segfault라고 생각합니다).
답변2
프로그램은 NFS 공유에 있는 파일에 액세스하려고 시도하지 않아도 계속 작동합니다. NFS 공유 폴더에서 파일을 읽거나 쓸 필요가 없다면 괜찮습니다.