☰

Linux 커널에서 현재 io 요청을 보내는 프로세스 찾기

tag-icon • tag-icon linux-kernel io
Linux 커널에서 현재 io 요청을 보내는 프로세스 찾기

나는 리눅스 커널을 깊이 파고들었습니다. io 요청을 추적하고 현재 io 요청을 보낸 프로세스가 정확히 무엇인지 알고 싶으십니까?

커널 문서에 따르면 현재 프로세스를 나타내는 current라는 구조가 있습니다.

그러나 분석인쇄block/blk-core.c의 기능이력서 제출이는 현재 프로세스가 아닌 것 같습니다.

내 거인쇄이것은:

printk(" Ata: in block/blk-core.c in submit_bio current task: %s pid:(%d): %s block %Lu on device %s (%u sectors)\n",
        current->comm, task_pid_nr(current),
            (rw & WRITE) ? "WRITE" : "READ",
            (unsigned long long)bio->bi_iter.bi_sector,
            bdevname(bio->bi_bdev, b),
            count);

그러나 출력은 내가 예상한 것과 다릅니다.

[Thu Dec 31 15:18:49 2015]  Ata: in block/blk-core.c in submit_bio current task: jbd2/sda1-8 pid:(494): WRITE block 54798672 on device sda1 (8 sectors)

출력은 현재 프로세스가제바드 2. ~에 따르면이 답변 제바드 2파일 시스템이 실행하는 기능입니다. 그에 비해 내 프로세스는DDPID: 2479.

현재 io 요청을 보낸 프로세스를 정확하게 찾는 방법은 무엇입니까? 그것은 마치오토프하고있다.

답변1

디스크 I/O 요청은 특정 프로세스를 추적할 수 없는 경우가 많습니다. 예를 들어 두 프로세스가 동시에 동일한 파일에 액세스하는 경우(즉, 프로세스 1의 요청을 처리하기 전에 프로세스 1이 요청하고 프로세스 2가 동일한 파일을 로드하도록 요청한 경우) 액세스를 다시 추적해야 합니다. 두 프로세스 모두. 지연된 쓰기의 경우 더 이상 존재하지 않는 프로세스로 인해 쓰기가 발생할 수 있습니다.

iotop은 프로세스당 I/O를 표시합니다.문서디스크 수준이 아닌 수준입니다. 파일 시스템 드라이버를 보면 current요청한 프로세스가 지정됩니다. 그러나 블록 장치 드라이버를 보고 있는 경우 프로세스가 파일 시스템을 우회하여 디스크에 직접 액세스하지 않는 한 I/O 요청은 내부 하위 시스템에서 발생합니다. 그렇기 때문에iotop에 대한 프로세스별 통계가 총계와 일치하지 않습니다.:총계는 디스크 수준에 대한 것입니다.

위에서 본 것처럼 일반적으로 요청을 발생시킨 프로세스까지 디스크 I/O 요청을 추적하는 것은 불가능합니다. 가능하다면 이런 종류의 추적을 허용하는 디버그 모드가 있는지는 모르겠습니다. 매우 리소스 집약적일 것으로 예상됩니다.

관련 정보