리눅스 퓨즈는 무엇을 의미합니까?

사용자 공간 파일 시스템을 지원하는 데 사용되는 Linux 커널 모듈을 FUSE라고 합니다. 퓨즈의 전체 이름은 "사용자 공간의 파일 시스템"이며 중국어로 "사용자 공간 파일 시스템"을 의미합니다. 사용자 모드에서 완전히 구현된 파일 시스템을 의미하며 Linux에서 특정 네트워크 공간을 마운트하는 데 사용되는 중요한 구성 요소입니다. 일반적인 운영 체제의.

이 튜토리얼의 운영 환경: linux7.3 시스템, Dell G3 컴퓨터.

리눅스 퓨즈란

사용자 공간의 파일 시스템은 사용자 모드에서 완전히 구현된 파일 시스템을 의미합니다. Linux에서 SSH와 같은 특정 네트워크 공간을 로컬 파일에 마운트하는 데 사용됩니다. 시스템 모듈, 관련 콘텐츠를 SourceForge에서 찾을 수 있습니다.

사용자 공간 파일 시스템을 지원하기 위해 Linux에서 사용하는 커널 모듈을 FUSE라고 합니다. FUSE라는 용어는 때때로 Linux의 사용자 공간 파일 시스템을 지칭합니다. 이는 일반적인 운영 체제의 중요한 부분입니다. 운영 체제는 전통적으로 커널 수준에서 파일 시스템에 대한 지원을 제공했습니다. 일반적으로 커널 모드 코드는 디버그하기 어렵고 생산성이 낮습니다.

소위 "사용자 모드 파일 시스템"은 파일 시스템의 데이터와 메타데이터가 사용자 모드 프로세스(이 프로세스를 "daemon"라고 함)에 의해 제공된다는 의미입니다. 마이크로 커널 운영 체제의 경우 사용자 모드에서 파일 시스템을 구현하는 것은 아무것도 아니지만 매크로 커널 Linux의 경우 의미가 다릅니다.

사용자 모드 파일 시스템이라고 하지만 커널의 참여가 전혀 필요하지 않다는 의미는 아닙니다. 왜냐하면 Linux에서는 파일에 대한 접근이 VFS에서 제공하는 커널 인터페이스를 통해 균일하게 수행되기 때문입니다. 따라서 프로세스("사용자"라고 함)가 데몬에 의해 구현된 파일 시스템에 액세스할 때 여전히 VFS를 거쳐야 합니다.

VFS가 사용자 프로세스로부터 파일 액세스 요청을 받고 파일이 사용자 모드 파일 시스템에 속해 있다고 판단하면(마운트 유형에 따라) 해당 요청을 "fuse"라는 커널 모듈로 전송합니다. 그런 다음 "fuse"는 요청을 데몬과 합의된 프로토콜 형식으로 변환하여 데몬 프로세스로 전송합니다.

이러한 3자 관계에서 "fuse" 커널 모듈은 VFS(사용자 프로세스라고도 할 수 있음) 간의 통신 채널을 설정하는 데 도움이 되는 것을 볼 수 있습니다. 일반 용어로 말하면 데몬의 역할은 실제로 "에이전트"의 역할입니다.

Linux에서 이 완전한 프레임워크의 구현은 FUSE(사용자 공간의 파일 시스템)입니다. 그림 1에서 볼 수 있듯이 빨간색 상자 안의 부분은 FUSE 유형 파일 시스템의 특정 구현이며 사용자 모드 파일 시스템 설계자가 재생할 수 있는 공간입니다. 현재 FUSE를 기반으로 구현된 파일 시스템이 100개가 넘습니다(일부 커널 기반 파일 시스템은 ZFS 및 NTFS와 같은 사용자 모드 파일 시스템으로 이식될 수도 있음). 이 기사에서는 기성 퓨즈를 사용합니다. 데모용 sshfs입니다.

먼저 퓨즈-sshfs 소프트웨어 패키지를 설치하고 다음 명령을 사용하여 파일 시스템을 마운트합니다(원격 시스템의 "remote-dir" 디렉터리를 로컬 시스템의 "local-dir" 디렉터리에 마운트).

sshfs :

그 후 "/sys/fs" 디렉토리에 "fuse"라는 폴더가 생성되며, "fuse" 커널 모듈이 로드되었으며(해당 장치는 "/dev/fuse") 로컬 마운트 디렉터리 유형이 "fuse.sshfs"가 되었습니다.

장치 노드를 생성하는 목적은 다음과 같습니다. 사용자 모드 제어에는 편리하지만 파일 시스템 수준 응용 프로그램의 경우 너무 많은 세부 정보가 제시되므로 ioctl()을 직접 사용하여 장치에 액세스하는 것은 여전히 ​​번거롭기 때문에 libfuse가 중간 계층으로 등장하고 데몬 프로세스에서 실제로 Fuse 장치 파일은 libfuse에서 제공하는 인터페이스를 통해 동작합니다.

You came and go

다음으로 퓨즈 커널 모듈과 데몬 프로세스 간의 구체적인 상호 작용 프로세스를 보려면 "fuse.sshfs" 파일 시스템에서 "touch" 명령을 통해 새 파일을 생성하는 예를 살펴보겠습니다. "sshfs") ( 코드 부분은 커널 버전 5.2.0 기준):

[1차]

시작은 권한 확인이지만 여기서 확인은 VFS 권한 확인과 동일하지 않습니다. 목적은 다른 사용자가 개인 퓨즈 파일 시스템에 액세스하는 것을 방지하는 것입니다.

그러면 파일 경로를 기준으로 파일의 inode를 찾습니다. 새로 생성된 파일이므로 inode가 커널의 inode 캐시에 없으므로 데몬에 "조회" 요청을 보내야 합니다.

이러한 요청은 보류 대기열에 들어가 대기합니다. 데몬 프로세스의 응답을 위해 사용자 프로세스는 절전 모드로 전환됩니다.

데몬으로서 sshfs 프로세스는 "/dev/fuse" 장치 파일을 읽어 데이터를 얻습니다. 차단 대기 상태에 빠집니다.

요청이 보류 중인 대기열에 도착하면 데몬 프로세스가 활성화되어 이러한 요청을 처리합니다. 처리된 요청은 처리 대기열으로 이동됩니다. 데몬 프로세스가 퓨즈 커널 모듈에 응답한 후 사용자 프로세스가 활성화되고 해당 요청이 처리 대기열에서 제거됩니다.

【두 번째 라운드】

다음 단계는 "touch" 명령을 실행할 때 트리거되는 다른 시스템 호출입니다. 이전에 액세스한 데이터/메타데이터라면 존재할 가능성이 높습니다. 캐시. 데이터/메타데이터의 이 부분에 다시 액세스할 때 퓨즈 커널 모듈은 사용자 공간으로 왕복할 필요 없이 자체적으로 이를 해결할 수 있습니다. 그렇지 않으면 처리를 위해 데몬 프로세스에 보고해야 합니다.

여기서 get_fuse_conn()은 퓨즈형 파일 시스템이 마운트될 때 생성되는 "fuse_conn" 구조체 인스턴스를 얻습니다. 데몬 프로세스와 커널 간의 링크로서 데몬 프로세스가 종료되거나 해당 퓨즈 파일 시스템이 제거되지 않는 한 연결은 항상 존재합니다.

데몬 프로세스 측면에서는 여전히 유사한 작업이 있습니다. 주목해야 할 것은 퓨즈_write/read() 와 fuse_dev_write/read() 이 두 가지 함수 시리즈의 차이점입니다. 전자는 사용자 프로세스가 퓨즈 파일 시스템의 파일에 액세스할 때 VFS 읽기 및 쓰기 요청입니다. , 이는 일반 파일입니다. 후자는 요청을 받고 응답하기 위해 데몬 프로세스가 퓨즈 커널 모듈을 나타내는 장치인 "/dev/fuse"를 읽고 쓰는 것입니다.

【세 번째 라운드】

퓨즈 커널 모듈과 데몬 프로세스 간의 마지막 상호 작용 라운드는 퓨즈 파일 시스템을 나타내는 슈퍼 블록에서 아이노드 번호를 얻고 이 메타데이터의 관련 정보를 채우는 것입니다. .

동전의 양면

퓨즈 파일 시스템에서는 비교적 간단한 "터치" 조작을 하더라도 사용자 모드와 관련된 커널 모드 사이의 전환이 비교적 빈번하다는 것을 어렵지 않게 찾아볼 수 있는데, 또한 여러 데이터 복사본이 함께 제공됩니다. 기존 커널 파일 시스템에 비해 전체 I/O 처리량은 더 낮고 대기 시간은 더 깁니다.

그렇다면 운영 체제가 지원하는 파일 시스템에서 퓨즈가 여전히 자리를 차지하는 이유는 무엇일까요? 말하자면, 사용자 모드에서 개발하면 많은 장점이 있습니다. 첫째, 디버깅이 쉽고 특히 새로운 파일 시스템 프로토타입의 빠른 검증에 적합하여 학술 연구 분야에서 매우 인기가 높습니다. 커널에서는 C언어만 사용할 수 있으며, 다양한 기능 라이브러리와 다양한 프로그래밍 언어를 사용할 수 있다.

두 번째로, 커널 버그로 인해 약간의 불일치로 인해 전체 시스템이 충돌하는 경우가 많습니다(호스트 충돌로 인해 호스트에서 실행 중인 모든 가상 머신이 충돌하기 때문에 이는 가상화된 응용 프로그램에서 더욱 심각합니다). 버그는 상대적으로 제한적입니다. 그래서 동전의 앞면은 개발에 편리하다는 점이지만 얼마나 편리한지는 결국

주관적

느낌이고, 뒷면은 성능에 미치는 영향이므로 객관적으로 확인할 수 있습니다. 실험 데이터. 그렇다면 퓨즈로 인한 손실을 비교적 정확하게 측정하려면 어떤 방법을 사용해야 할까요? 우리는 이전에 사용했던 퓨즈-sshfs를 계속 사용하지만 여기서는 더 이상 원격 마운트를 사용하지 않고 로컬 마운트를 사용합니다(로컬 머신의 "dir-src" 디렉토리가 ext4 파일 시스템에 있다고 가정):

sshfs localhost:

데몬 프로세스가 요청을 받으면 ext4 커널 모듈에 액세스하기 위해 커널에 다시 들어가야 합니다(이 파일 시스템 모드를 "스택 가능"이라고 함) "):

퓨즈 파일 시스템에 write() 요청을 발행하는 사용자 프로세스를 예로 들어 보겠습니다. 오른쪽의 빨간색 상자는 기본 ext4 호출 경로이고 왼쪽의 추가 경로는 경로입니다. :

이 문서에 제공된 데이터에 따르면 이 시스템 호출에 사용된 "getxattr"에 의해 형성된 요청에는 "사용자-커널" 상호 작용 양의 2배가 필요합니다.

순차 쓰기

의 경우 기본 ext4 파일 시스템에 비해 I/O 처리량이 27% 감소하고 임의 쓰기가 44% 감소합니다. 그러나 퓨즈 파일 시스템이 탄생한 지 수년이 지난 후에도 모든 사람들은 여전히 ​​이에 대한 많은 최적화 방법을 생각해 냈습니다. 예를 들어 순차적으로 읽고 쓰는 경우 일괄적으로 데몬 프로세스에 요청을 보내도록 설계할 수 있습니다(단, 무작위 읽기 및 쓰기는 적합하지 않습니다). 또한

스플라이싱

이라는 제로 복사 기술이 있습니다. Linux 커널에서 제공하는 스플라이싱 메커니즘을 사용하면 사용자 공간에서 두 커널의 메모리 버퍼 데이터를 복사하지 않고 전송할 수 있으므로 특히 스택형 모드에 적합합니다. 퓨즈 커널 모듈은 데이터를 ext4 커널 모듈에 직접 전송합니다(단, 스플라이싱은 일반적으로 4K를 초과하는 요청에 사용되며 소량의 데이터를 읽고 쓰는 데 사용되지 않습니다).

이러한 노력 끝에 퓨즈 파일 시스템은 어떤 성능을 얻을 수 있을까요? 이 보고서에 나열된 테스트 결과에 따르면 기본 ext4와 비교하여 최상의 경우 퓨즈의 성능 손실을 5% 미만으로 제어할 수 있지만 최악의 경우 83%에 이릅니다. 동시에 CPU 리소스 사용량도 31% 증가했습니다.

Android v4.4에서 v7.0 사이에 존재했던 sdcard 데몬부터 최근 Ceph 및 GlusterFS까지 모두 FUSE 기반 구현을 채택했거나 현재 채택하고 있습니다. FUSE는 네트워크 파일 시스템 및 가상화 응용 프로그램에서 유용성을 보여주었습니다. 그 출현과 개발은 커널 모드에서 구현된 파일 시스템을 대체하는 것이 아니라 유용한 보완책으로 사용됩니다(이론적으로 FUSE는 루트 파일 시스템을 구현하는 데에도 사용할 수 있지만 이는 권장되지 않습니다. "할 수 있다"와 "해야 한다"는 서로 다릅니다. 관련 추천: "

Linux 비디오 튜토리얼

"

위 내용은 리눅스 퓨즈는 무엇을 의미합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!