☰

Linux에서 /proc가 오버레이fs가 될 수 없는 이유는 무엇입니까?

tag-icon • tag-icon linux mount proc overlayfs
Linux에서 /proc가 오버레이fs가 될 수 없는 이유는 무엇입니까?

Linux에서 다음 명령을 실행하면(4.4.59 및 4.9.8에서 테스트됨) 실패합니다.

mkdir -p /tmp/proc
mount -t overlay overlay -o lowerdir=/proc:/tmp/proc /tmp/proc

오류 메시지가 있습니다 dmesg.

overlayfs: maximum fs stacking depth exceeded

/proc파일 시스템을 덮는 레이어가 될 수 없는 이유는 무엇입니까 ? 로
교체하거나 문제 없이 설치하면 다음과 같이 보입니다 ./proc/dev/sys/proc

PS 사용 사례는 보다 안전한 chroot환경을 만드는 것인데, 이를 /dev수행하려고 합니다. 알려진 해결 방법은 2가지입니다./sys/procchroot

  1. 읽기 전용 바인드 마운트. 제한은 필수 명령이 아닌 두 명령입니다.
  2. 읽기 전용 특수 마운트: mount -t proc -o ro none /tmp/proc제한 사항은 하위 마운트가 자동으로 매핑되지 않는다는 것입니다.

/dev어쨌든 왜 오버레이 가 /sys제대로 작동하는지 여전히 궁금 하지만 /proc작동하지 않습니다.

문제가 마이그레이션되었습니다.스택 오버플로에서.

답변1

https://github.com/torvalds/linux/commit/e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9

    /*
     * procfs isn't actually a stacking filesystem; however, there is
     * too much magic going on inside it to permit stacking things on
     * top of it
     */
s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;

이는 유익한 답변이 아닐 수도 있지만 커널 개발자가 특별히 지원하지 않는 것입니다.

답변2

Grepping의 "깊이" 발견은 /usr/src/linux/fs/overlayfs현재 스택 깊이에 대한 간단한 검사입니다 FILESYSTEM_MAX_STACK_DEPTH. 포함 파일을 검색하면 FILESYSTEM_MAX_STACK_DEPTH2에 정의되어 있는 것으로 나타났습니다 /usr/src/linux/include/linux/fs.h. 댓글은 말한다

fs 스택의 최대 레이어 수입니다. 커널 스택 오버플로를 방지하는 데 필요한 제한

-filesystem이 또는에 비해 다른 수준의 간접 참조를 추가하기 때문에 분명히 proc스택 깊이가 초과되었습니다. 더 깊게 쌓을 수 없는 분명한 이유가 없으므로 커널을 늘리고 다시 컴파일하여 작동하는지 확인하십시오. 이로 인해 커널이 더 많은 스택을 사용하게 되므로 일반적으로 더 많은 메모리가 필요하고 속도가 느려질 수 있습니다. 구현에 대한 세부 정보는 모르겠습니다.devsysFILESYSTEM_MAX_STACK_DEPTH

편집하다댓글에 응답하기

내 생각에는 proc파일 시스템이 각 모듈의 파일을 추적하여 모듈이 제거될 때 해당 파일을 삭제할 수 있어야 한다는 것입니다. 기본적으로 모든 모듈에 대한 오버레이 파일 시스템입니다. 그런데 이를 검증하기 위해서는 소스코드를 자세히 읽어야 했습니다(소스코드도 읽어보실 수 있습니다. :-).

스택 깊이는 stack_depth슈퍼블록 구조의 범위 내에 있으므로 이를 표시하려면 커널 데이터 구조에 액세스할 수 있는 방법이 필요합니다. 일부 커널 디버깅 도구가 이 작업을 수행할 수 있다고 생각합니다(또는 항상 표시하기 위해 커널 확장/모듈을 작성할 수 있음). 그러나 구체적인 방법은 모르겠습니다.

관련 정보