Linux의 가상 파일 시스템: 왜 필요하고 어떻게 작동합니까? 2 부

안녕하세요 여러분, "Linux의 가상 파일 시스템: 왜 필요하며 어떻게 작동합니까?" 출판물의 두 번째 부분을 공유합니다. 첫 번째 부분을 읽을 수 있습니다 여기에. 이 일련의 간행물은 해당 과정의 새로운 스트림 출시와 일치하도록 맞춰져 있음을 상기시켜 드리겠습니다. "리눅스 관리자", 곧 시작됩니다.

eBPF 및 bcc 도구를 사용하여 VFS를 모니터링하는 방법

커널이 파일에서 어떻게 작동하는지 이해하는 가장 쉬운 방법 sysfs 실제로 보는 것인데, ARM64를 시청하는 가장 쉬운 방법은 eBPF를 사용하는 것입니다. eBPF(Berkeley Packet Filter의 약어)는 다음에서 실행되는 가상 머신으로 구성됩니다. 핵심, 권한이 있는 사용자가 요청할 수 있는 것(query) 명령줄에서. 커널 소스는 독자에게 커널이 무엇을 할 수 있는지 알려줍니다. 로드된 시스템에서 eBPF 도구를 실행하면 커널이 실제로 수행하는 작업이 표시됩니다.

다행히 eBPF 사용을 시작하는 것은 도구의 도움으로 매우 쉽습니다. 숨은 참조, 일반 배포판에서 패키지로 제공됨 Linux 그리고 자세하게 문서화되어 있어요 버나드 그레그. 도구 bcc C 코드가 약간 삽입된 Python 스크립트이므로 두 언어에 익숙한 사람이라면 누구나 쉽게 수정할 수 있습니다. 안에 bcc/tools 80개의 Python 스크립트가 있으며 이는 개발자나 시스템 관리자가 문제 해결에 적합한 것을 선택할 수 있음을 의미합니다.
실행 중인 시스템에서 VFS가 수행하는 작업에 대한 최소한의 피상적인 아이디어를 얻으려면 다음을 시도하십시오. vfscount 또는 vfsstat. 예를 들어 수십 건의 호출이 표시됩니다. vfs_open() 그리고 "그의 친구들"은 말 그대로 매초마다 일어납니다.

vfsstat.py 단순히 VFS 함수 호출을 계산하는 C 코드 삽입이 포함된 Python 스크립트입니다.

좀 더 간단한 예를 들어 USB 플래시 드라이브를 컴퓨터에 삽입하고 시스템이 이를 감지하면 어떤 일이 발생하는지 살펴보겠습니다.

eBPF를 사용하면 무슨 일이 일어나고 있는지 확인할 수 있습니다. /sysUSB 플래시 드라이브를 삽입한 경우. 여기에는 간단하고 복잡한 예가 나와 있습니다.

위에 표시된 예에서, bcc инструмент 추적.py 명령이 실행될 때 메시지를 인쇄합니다. sysfs_create_files(). 우리는 그것을 본다 sysfs_create_files() 사용하여 출시되었습니다. kworker 플래시 드라이브를 삽입했다는 사실에 대한 응답으로 스트리밍했는데 어떤 파일이 생성 되었습니까? 두 번째 예는 eBPF의 강력한 기능을 보여줍니다. 여기 trace.py 커널 역추적(-K 옵션)과 생성된 파일 이름을 인쇄합니다. sysfs_create_files(). 단일 명령문 삽입은 LLVM을 실행하는 Python 스크립트에서 제공하는 쉽게 인식할 수 있는 형식 문자열을 포함하는 C 코드입니다. 적시 컴파일러. 이 줄을 컴파일하고 커널 내부의 가상 머신에서 실행합니다. 전체 기능 서명 sysfs_create_files () 형식 문자열이 매개변수 중 하나를 참조할 수 있도록 두 번째 명령에서 재현되어야 합니다. 이 C 코드 조각의 오류로 인해 C 컴파일러에서 인식 가능한 오류가 발생합니다. 예를 들어 -l 매개변수를 생략하면 "BPF 텍스트 컴파일에 실패했습니다."라는 메시지가 표시됩니다. C 및 Python에 익숙한 개발자는 도구를 찾을 수 있습니다. bcc 확장 및 변경이 쉽습니다.

USB 드라이브가 삽입되면 커널 역추적에 PID 7711이 스레드인 것으로 표시됩니다. kworker파일을 만든 사람 «events» в sysfs. 이에 따라, sysfs_remove_files() 드라이브를 제거하면 파일이 삭제된다는 메시지가 표시됩니다. events, 이는 참조 카운팅의 일반적인 개념에 해당합니다. 동시에 시청 중 sysfs_create_link () USB 드라이브를 삽입하는 동안 eBPF를 사용하면 최소 48개의 심볼릭 링크가 생성된 것으로 표시됩니다.

그렇다면 이벤트 파일의 요점은 무엇입니까? 용법 스코프 검색용 __device_add_disk(), 원인을 보여줍니다. disk_add_events (), 그리고 "media_change"또는 "eject_request" 이벤트 파일에 기록될 수 있습니다. 여기서 커널 블록 계층은 "디스크"가 나타났다가 꺼졌다는 사실을 사용자 공간에 알립니다. USB 드라이브를 삽입하는 이 연구 방법이 소스에서 순수하게 작동하는 방식을 알아내려고 시도하는 것과 비교하여 얼마나 유익한지 확인하세요.

읽기 전용 루트 파일 시스템으로 임베디드 장치 활성화

물론 소켓에서 플러그를 뽑아 서버나 컴퓨터를 끄는 사람은 아무도 없습니다. 그런데 왜? 이는 물리적 저장 장치에 마운트된 파일 시스템에 쓰기 지연이 있을 수 있고 해당 상태를 기록하는 데이터 구조가 저장소에 대한 쓰기와 동기화되지 않을 수 있기 때문입니다. 이런 일이 발생하면 시스템 소유자는 유틸리티를 시작하기 위해 다음 부팅까지 기다려야 합니다. fsck filesystem-recovery 최악의 경우 데이터가 손실될 수 있습니다.

그러나 우리 모두는 라우터, 온도 조절기, 자동차뿐만 아니라 많은 IoT 장치가 이제 Linux를 실행한다는 것을 알고 있습니다. 이러한 장치 중 다수에는 사용자 인터페이스가 거의 또는 전혀 없으며 "완전히" 끌 수 있는 방법이 없습니다. 제어 장치의 전원이 꺼졌을 때 배터리가 방전된 자동차의 시동을 걸었다고 상상해 보십시오. Linux 끊임없이 위아래로 점프합니다. 시스템이 오래 걸리지 않고 부팅되는 이유는 무엇입니까? fsck마침내 엔진은 언제 작동하기 시작합니까? 대답은 간단합니다. 임베디드 장치는 루트 파일 시스템에 의존합니다. 읽기 전용 (약어 ro-rootfs (읽기 전용 루트 파일 시스템)).

ro-rootfs 진정성보다 덜 분명한 많은 이점을 제공합니다. 한 가지 장점은 악성코드가 데이터에 쓸 수 없다는 것입니다. /usr 또는 /lib, Linux 프로세스가 거기에 쓸 수 없는 경우. 또 다른 점은 지원 인력이 명목상 현장 시스템과 동일한 로컬 시스템에 의존하기 때문에 원격 장치의 현장 지원에는 대체로 불변적인 파일 시스템이 중요하다는 것입니다. 아마도 가장 중요하지만 가장 교활한 이점은 ro-rootfs가 개발자에게 시스템 설계 단계에서 어떤 시스템 개체가 불변인지 결정하도록 강요한다는 것입니다. const 변수는 종종 프로그래밍 언어에 포함되어 있기 때문에 ro-rootfs로 작업하는 것은 어색하고 고통스러울 수 있지만 그 이점은 추가 오버헤드를 쉽게 정당화합니다.

창조 rootfs 읽기 전용은 임베디드 개발자에게 추가적인 노력이 필요하며, 여기서 VFS가 등장합니다. Linux에서는 파일이 다음 위치에 있어야 합니다. /var 쓰기 가능했으며 또한 임베디드 시스템을 실행하는 많은 인기 있는 애플리케이션이 구성을 생성하려고 시도할 것입니다. dot-files в $HOME. 홈 디렉토리의 구성 파일에 대한 한 가지 솔루션은 일반적으로 홈 디렉토리에 있는 구성 파일을 미리 생성하여 빌드하는 것입니다. rootfs. 에 /var 한 가지 가능한 접근 방식은 별도의 쓰기 가능한 파티션에 마운트하는 것입니다. / 읽기 전용으로 마운트되었습니다. 또 다른 인기 있는 대안은 바인드 또는 오버레이 마운트를 사용하는 것입니다.

연결 가능하고 쌓을 수 있는 마운트, 컨테이너에서의 사용

명령 실행 man mount 개발자와 시스템 관리자가 한 경로에서 파일 시스템을 생성한 다음 이를 다른 경로의 애플리케이션에 노출할 수 있는 기능을 제공하는 바인딩 및 오버레이 가능한 마운트에 대해 배울 수 있는 가장 좋은 방법입니다. 임베디드 시스템의 경우 이는 파일을 저장할 수 있는 기능을 의미합니다. /var 읽기 전용 플래시 드라이브에 있지만 오버레이 또는 연결 가능한 마운트 경로는 tmpfs в /var 로드할 때 응용 프로그램이 거기에 메모를 쓸 수 있습니다(스크롤). 다음에 변경사항을 사용 설정할 때 /var 잃게 될 것이다. 오버레이 마운트는 다음과 같은 결합을 생성합니다. tmpfs 및 기본 파일 시스템을 사용하여 기존 파일을 표면적으로 변경할 수 있습니다. ro-tootf 바인딩 가능한 마운트는 새 마운트를 비울 수 있습니다. tmpfs 쓰기 가능한 폴더 표시 ro-rootfs 방법. 하는 동안 overlayfs 이게 맞다(proper) 파일 시스템 유형, 바인딩 가능한 마운트가 구현됨 VFS 네임스페이스.

오버레이와 연결 가능한 마운트에 대한 설명을 보면 누구도 놀라지 않을 것입니다. Linux 컨테이너 그들은 적극적으로 사용됩니다. 우리가 사용할 때 무슨 일이 일어나는지 봅시다 시스템 nspawn 도구를 사용하여 컨테이너를 실행하려면 mountsnoop 부터 bcc.

도전 system-nspawn 실행 중에 컨테이너를 시작합니다. mountsnoop.py.

무슨 일이 일어났는지 봅시다:

출시 mountsnoop 컨테이너가 "부팅"되는 동안 컨테이너의 런타임은 연결되는 마운트에 크게 의존한다는 것을 보여줍니다(긴 출력의 시작 부분만 표시됨).

여기에 systemd-nspawn 선택한 파일을 제공합니다 procfs и sysfs 호스트를 컨테이너에 대한 경로로 사용 rootfs. 게다가 MS_BIND 바인딩 마운트를 설정하는 플래그와 마운트의 다른 일부 플래그는 호스트와 컨테이너 네임스페이스에 대한 변경 사항 간의 관계를 정의합니다. 예를 들어 연결된 마운트는 다음 중 하나에 대한 변경 사항을 건너뛸 수 있습니다. /proc и /sys 컨테이너에 넣거나 호출에 따라 숨길 수 있습니다.

결론

Linux의 내부 작동 방식을 이해하는 것은 불가능한 작업처럼 보일 수 있습니다. 커널 자체에는 엄청난 양의 코드가 포함되어 있고 Linux 사용자 공간 응용 프로그램과 다음과 같은 C 라이브러리의 시스템 호출 인터페이스는 제쳐두고 있기 때문입니다. glibc. 발전하는 한 가지 방법은 시스템 호출과 사용자 공간 헤더는 물론 테이블과 같은 주요 내부 커널 인터페이스를 이해하는 데 중점을 두고 하나의 커널 하위 시스템의 소스 코드를 읽는 것입니다. file_operations. 파일 작업은 "모든 것이 파일임" 원칙을 제공하므로 관리하기가 특히 즐겁습니다. 최상위 디렉터리의 C 커널 소스 파일 fs/ 널리 사용되는 파일 시스템과 저장 장치 간에 광범위하고 상대적으로 간단한 호환성을 제공하는 래퍼 계층인 가상 파일 시스템의 구현을 제시합니다. Linux 네임스페이스를 통한 연결 및 오버레이 마운트는 읽기 전용 컨테이너와 루트 파일 시스템 생성을 가능하게 하는 VFS의 마법입니다. 소스 코드, eBPF 핵심 도구 및 인터페이스 검사와 결합 bcc
핵심 탐색을 그 어느 때보다 쉽게 ​​만듭니다.

친구 여러분, 이 기사가 도움이 되었습니까? 혹시 의견이나 의견이 있으신가요? 그리고 Linux 관리자 과정에 관심이 있는 분들을 초대합니다. 오픈 데이, 18월 XNUMX일에 진행됩니다.

첫 번째 부분.

출처 : habr.com