Как получить физический адрес файла в оперативной памяти? [закрыт]

Я нашел несколько связанных постов:

Как увидеть информацию внутри структуры данных inode

Можно ли найти физический адрес файла на диске?

Но ничего не отвечает на мой вопрос. У меня есть процесс, который непрерывно читает файл, и я хотел бы получить физический адрес файла, который он читает. Я знаю, какой файл он читает. Обсуждаемый процесс не использует mmap.

Как я могу получить физический адрес этого файла? Я предполагаю, что могу получить его адрес в оперативной памяти. Предпочтительно, если возможно, используя командные утилиты вместо того, чтобы писать приложение на C.

Обсуждаемый процесс:

int main(void)
{
    int iFd = open("/some/path/file.txt",O_RDWR);
    if (iFd < 0)
    {
        fprintf(stderr, "Не удалось открыть файл: %s\n", strerror(errno));
        return -1;
    }


    while(1)
    {
        uint8_t tmp[10]={0};
        read(iFd, tmp, sizeof tmp);
        (void) tmp;
    }

    close(iFd);

    return 0;
}

Я смотрел в /proc, но файл там не отображается:

# cat /proc/<PID процесса>/maps
555fa58000-555fa59000 r-xp 00000000 b3:02 34817                          /some/path/myProcess
555fa68000-555fa69000 r--p 00000000 b3:02 34817                          /some/path/myProcess
555fa69000-555fa6a000 rw-p 00001000 b3:02 34817                          /some/path/myProcess
7fb3970000-7fb3ac3000 r-xp 00000000 b3:02 786                            /lib/libc-2.31.so
7fb3ac3000-7fb3ad3000 ---p 00153000 b3:02 786                            /lib/libc-2.31.so
7fb3ad3000-7fb3ad6000 r--p 00153000 b3:02 786                            /lib/libc-2.31.so
7fb3ad6000-7fb3ad9000 rw-p 00156000 b3:02 786                            /lib/libc-2.31.so
7fb3ad9000-7fb3adc000 rw-p 00000000 00:00 0
7fb3adc000-7fb3afd000 r-xp 00000000 b3:02 778                            /lib/ld-2.31.so
7fb3b04000-7fb3b06000 rw-p 00000000 00:00 0
7fb3b0a000-7fb3b0b000 r--p 00000000 00:00 0                              [vvar]
7fb3b0b000-7fb3b0c000 r-xp 00000000 00:00 0                              [vdso]
7fb3b0c000-7fb3b0d000 r--p 00020000 b3:02 778                            /lib/ld-2.31.so
7fb3b0d000-7fb3b0f000 rw-p 00021000 b3:02 778                            /lib/ld-2.31.so
7ff5eb9000-7ff5eda000 rw-p 00000000 00:00 0                              [stack]

Физический адрес в оперативной памяти не имеет значения, кроме как для ядра и физической оперативной памяти. Если вы не используете логический зонд для материнской платы или не пытаетесь диагностировать неисправную память или что-то подобное, физический адрес не имеет значения и не полезен для чего-либо. Нет API пользовательского пространства, который позволял бы вам получить доступ к физической памяти или использовать физический адрес. Ядро раньше имело (очень традиционное) устройство для доступа к физической памяти, но это было удалено давно как риск безопасности и не очень полезно.

Другим исключением будет, если вы работаете в ядре, в этом случае есть API ядра для получения этой информации.

Без mmap, если файл вообще находится в физической памяти, он там только эфемерно, и эти страницы могут быть освобождены в любой момент. Любое возможное использование физического адреса вне ядра будет соревнованием условий.

Главная цель mmap – назначить виртуальный адрес частям файла. Просто потому, что вы сопоставили файл по-прежнему не означает, что у него есть физический адрес или что какая-либо часть файла находится в памяти. Только когда вы пытаетесь получить доступ к этой виртуальной памяти, она физически загружается в память, и даже тогда она по-прежнему будет эфемерной.

Имело бы больше смысла спросить, как определить, какие дисковые блоки использует файл. А затем возможно, было бы интересно узнать, какая память кеширует эти блоки, но это все равно будет эфемерным и не очень полезным.