Python으로 FUSE 파일 시스템 작성 가이드 시작

• 수업용 파일 시스템 프로젝트와 ChiPy 발표 준비가 맞물리며, Python으로 FUSE 기반 파일 시스템을 단계별로 만드는 GitLab 가이드가 시작됨
• 수업에서 쓰는 FIUnamFS는 연속 파일 할당, 하위 디렉터리 미지원, 1.44MB 플로피 디스크 크기 제한이 있는 장난감 파일 시스템임
• 여섯 학기 동안 학기당 30~40명의 학생에게 과제를 냈지만 FUSE 구현 제출은 한 명뿐이라, 따라 하기 쉬운 Python FUSE 자료의 필요성이 커짐
• 새 가이드는 빈 파일 시스템에서 시작해 시스템 호출과 기능을 더하는 점진적 과제 형식이며, RAM 기반 읽기/쓰기와 읽기 전용 패스스루 구현까지 다룸
• DNS, Markdown 즉석 컴파일, unzip, 주석 제거 파일 시스템 같은 짧은 예제가 함께 있어 학생들이 실용적 예시로 FUSE를 익힐 수 있음

---

수업 프로젝트에서 출발한 Python FUSE 가이드

• DebConf22에서 Chicago Python User Group 발표 제안을 받은 뒤, DebConf24에서 다시 이야기가 나오며 Python 발표 주제를 찾게 됨
• Python을 주력 언어로 여기지는 않지만, 학생들이 가장 잘 따라오는 언어라 수업에서는 Python을 사용함
• 수업 프로젝트인 FIUnamFS는 “Facultad de Ingeniería, Universidad Nacional Autónoma de México”의 약자로, 멕시코 국립자치대학교 공학부 수업에서 쓰는 파일 시스템임
  • 연속 파일 할당 기반임
  • 하위 디렉터리를 지원하지 않음
  • 보통 1.44MB 플로피 디스크 크기로 제한됨
  • 명세와 구현이 쉬운 장난감 파일 시스템으로 쓰임
• 단순 메뉴보다 더 다듬어진 인터페이스를 만들도록 학생들에게 요구해 왔고, 사용자가 의식하지 않고 FIUnamFS를 쓰려면 FUSE가 적합하다고 봄
• 이 프로젝트를 여섯 학기 동안 학기당 30~40명에게 냈지만, 실제 FUSE 구현을 제출한 학생은 한 명뿐이었음

기존 자료의 한계와 선택지

• Python FUSE 예제와 글은 이미 있었지만, 단독으로 따라가기에는 부족하거나 오래된 자료가 많았음
  • python-fuse 예제
  • Stavros의 passthrough filesystem
  • Dave Filesystem
  • Matteo Bertozzi의 PyCon4 발표
• Python에서 쓸 수 있는 FUSE 인터페이스도 하나로 통일돼 있지 않아, 어디서 시작할지 고르기 어렵다는 문제가 있음
  • python-fuse
  • Pyfuse
  • Fusepy

GitLab 가이드의 구성

• 새 GitLab 프로젝트 a hand-holding guide to writing FUSE-based filesystems in Python는 여러 동작하는 FUSE 파일 시스템 구현을 단계별로 보여줌
  • 일부는 RAM 기반으로 동작함
  • 일부는 패스스루 기반으로 구현됨
  • FIUnamFS 같은 구현을 위해 의사 블록 장치 기반 파일 시스템도 추가할 계획임
• 현재 다섯 개의 단계적 파일이 들어 있으며, 가장 단순한 빈 파일 시스템에서 시작해 시스템 호출과 기능을 하나씩 더함
  • empty filesystem
  • read-write filesystem in RAM with basic stat() support
  • read-only passthrough filesystem
• 학생들이 흥미를 느낄 만한 짧고 유용한 예제도 함께 들어 있음
  • DNS Filesystem
  • on-the-fly markdown compiling filesystem
  • unzip filesystem
  • uncomment filesystem
• 예제들은 수십 줄 수준이라 수업에서 다루기 쉽고, uncommentfs는 주석과 공백을 자동으로 제거함

발표 일정과 공개 자료

• ChiPy 발표는 2024년 10월 10일 18:30 GMT-6에 온라인으로 진행됨
• 같은 주제는 Jornadas Regionales de Software Libre와 nerdear.la에서도 발표 예정임
• 발표 후 영상도 공개됨
  • ChiPy 발표 영상: A hand-holding guide to writing FUSE-based filesystems in Python
  • 스페인어 발표 영상: Aprendiendo y enseñando a escribir sistemas de archivo en espacio de usuario con FUSE y Python

[GN⁺]

Hacker News 의견들

• libfuse GitHub의 [0]에는 C/C++용 예제가 복잡도별로 잘 정리돼 있음
  passthrough.c는 기존 파일시스템을 미러링하지만 “성능이 끔찍하다”고 되어 있고, passthrough_fh.c는 “그만큼 나쁘진 않다”고 함
  passthrough_ll.c는 저수준 API로 구현돼 “셋 중 가장 덜 나쁘다”고 하며, passthrough_hp.cc는 C++로 작성된 고성능 버전임
  메모해 둔 흥미로운 FUSE 프로젝트로는 대용량 파일 분할 [1], ZFS 증분 스냅샷을 파일로 표시 [2], 투명 파일시스템 압축 [3], 아카이브를 파일시스템으로 마운트하는 옵션 [4], [5]가 있음
  [0] https://github.com/libfuse/libfuse/tree/master/example
  [1] https://github.com/seiferma/splitviewfuse
  [2] https://github.com/UNFmontreal/zfs_fuse_snapshot
  [3] https://github.com/FS-make-simple/fusecompress
  [4] https://github.com/google/fuse-archive
  [5] https://github.com/mxmlnkn/ratarmount

  • [2]가 좋은 코드 예제일 수는 있지만, 이 기능은 이미 ZFS에 내장돼 있음
    모든 데이터셋의 마운트 지점에는 ls -A에도 보이지 않는 숨김 .zfs 폴더가 있고, 있다고 믿고 직접 cd하면 됨
    그 아래 snapshot 폴더가 있으며, 그 안에 해당 데이터셋의 각 스냅샷 폴더가 있고 스냅샷의 파일들이 들어 있음
    예를 들어 zrepl_20241011_010143_000 스냅샷의 /etc/hosts는 /.zfs/snapshot/zrepl_20241011_010143_000/etc/hosts에 있음
    이런 마법 같은 숨김 동작이 싫다면 zfs set snapdir=visible 로 일반 폴더처럼 보이게 설정할 수도 있음
  • 얼마 전 Linux에서 대소문자 구분을 우회해야 하는 용도로 FUSE를 떠올리고 있었음
    관련 링크들이 반갑고, 감이 좀 녹슬어서 도움이 됐던 FUSE 튜토리얼이나 가이드가 있으면 받고 싶음

• FUSE를 좋아하지만 유일한 선택지는 아니며, 얼마 전 9p 프로토콜로 가상 파일시스템을 구현해 보니 꽤 재미있었음
  기억으로는 py9p를 썼고 Python 경험은 fuse-python보다 훨씬 나았음
  원하면 9pfuse로 9p 서비스를 FUSE를 통해 마운트할 수 있지만, 나는 커널 v9fs 클라이언트를 사용했음
  단순히 네트워크 너머로 파일시스템을 전달하려는 목적이라면 diod 9p 서버를 썼던 것 같고, 전체적으로 살펴볼 만한 작은 생태계임

  • 9p는 정말 훌륭한 작은 프로토콜이고, diod[0]에는 프로토콜 자체 문서도 꽤 있으며 내용도 단순함
    내 메모는 [1]에 있지만 대부분 원문 자료 링크 모음임
    FUSE도 좋지만 9P는 더 범용적이고, Windows까지 포함해 여러 곳에 품질 좋은 구현이 있음
    다만 9p의 성능 특성은 확신이 없고, 느리다는 이야기를 본 적은 있지만 확정적인 자료는 못 봤음
    벤치마크나 정보가 있는지 궁금함
    [0]: https://github.com/chaos/diod/blob/master/protocol.md
    [1]: https://athenaeum.wiki/Zettelkasten/9p
  • 18개월쯤 전에 HTTPS URL 앞에 FUSE를 두는 실험을 했음
    큰 파일을 먼저 다운로드하지 않고 로컬 파일처럼 임의 읽기하고 싶었음
    겪은 고통 중 하나는 FUSE의 블록 크기가 너무 작아서, 백엔드로 가는 HTTP 호출의 지연과 churn이 커졌고 꽤 복잡한 캐싱/미리 읽기 로직이 필요했다는 점임
    커널의 미리 읽기 로직은 전혀 작동하지 않는 것처럼 보였고, 당시에는 유도 방법을 찾지 못한 것 외엔 깊게 조사하지 않았음
  • qemu에서는 9p(virtio-9p)보다 fuse(virtiofs) 를 쓰면 성능이 더 좋을 수 있음
    FAQ는 https://virtio-fs.gitlab.io에서 볼 수 있음
  • py9p는 마지막 릴리스가 2013년이고 아직 “beta”로 표시돼 있는 것 같음
    그래도 멋진 프로젝트임

• 한 달 전에 정확히 같은 과정을 거쳐야 했을 때 이걸 알았더라면 좋았겠음
  Jira를 덜 짜증나게 다루려는 절박한 시도로, 내부 이슈 분류를 이용해 트리를 만드는 jira-as-filesystem 프로젝트를 떠올렸음
  디렉터리는 이슈를, 파일은 이슈 필드를, 하위 디렉터리는 연결된 이슈를 나타내게 했고 결국 fuse-python을 선택함
  한동안 작업을 못 했지만 이미 추상화에서 문제가 생겼음
  디렉터리 이름을 이슈 ID만으로 쓰면 자동화는 쉬운데, ls를 하면 알아보기 힘든 ID만 잔뜩 보여서 사람이 탐색하기 어렵다 보니, 이슈 ID 뒤에 슬러그화한 요약을 붙이는 병렬 -with-summary 디렉터리 유형을 추가했음

  • 좋은 아이디어라는 뜻은 아니지만, 전체 Jira 환경의 심볼릭 링크 버전을 최신으로 유지하는 데몬은 어떨까 싶음
    원본 파일용 jira-as-filesystem 하나를 두고, 사람이 탐색하고 상호작용할 용도로는 같은 파일을 관련된 여러 위치에 여러 링크로 배치한 심볼릭 링크 트리를 두는 방식임
    이해가 부족해서 필요 이상으로 층을 더하는 것일 수는 있지만, 기술적으로는 현재 말한 추상화 문제를 풀 수 있을 듯함
  • Unix 파일시스템에서 같은 대상을 두 방식으로 참조하는 건 일반적임
    현대 Linux에서는 디스크를 블록 장치와 UUID로 모두 참조하므로, 이 접근은 괜찮고 기대에도 부합한다고 봄
    다만 개인적으로는 JIRA 자체도 충분히 복잡해서 쓰진 않을 것 같음
  • GitHub에는 jirafs 계열이 꽤 있음
    예: https://github.com/coddingtonbear/jirafs
  • 그냥 1234-human-sense처럼 하면 안 될까?
    두 종류의 정보를 모두 담고 있고 파싱도 쉬워 보임
  • 만든 솔루션을 오픈소스로 공개할 가능성이 있을까?

• 절충점, 성능, 기능이 제각각인 FUSE 마운트 옵션이 정말 많음
  s3fs, goofys, seaweed, minio, Google Drive 등도 있고, JuiceFS는 객체 저장소를 마운트한 뒤 전통적인 파일시스템에서 기대하는 메타데이터를 갖춘 POSIX 방식으로 접근하는 용도에 꽤 흥미로움
  https://juicefs.com

• 좋음
  인접한 질문으로, 최근에는 더 널리 지원되는 프로토콜이라서 NFS 기반 파일시스템을 구현하는 경우를 봄
  rclone이 Mac에서 이렇게 하는 것 같은데, 이 접근법에 대한 가이드나 비교 자료가 있을까?

  • 재미있는 사실: 최근 macOS 버전에서는 macFUSE를 설치하려면 보안 기능을 꺼야 하는데, 훌륭한 fuse-t가 있음
    거의 대체품처럼 동작하고, 커널 확장도 필요 없으며, 백그라운드에서 NFS 서버를 열고 macOS 기능으로 마운트함
    성능도 꽤 좋음
  • Rust 예제: https://github.com/xetdata/nfsserve

• 완성된 제품이 어떤 모습인지 보고 싶다면, 가상 파일시스템이 있는 음악 관리자 azuline/rosé를 보면 좋음
  주석, 설명, 타입, 테스트가 많은 훌륭한 코드베이스라 배우기 쉬울 것임
  https://github.com/azuline/rose

• FUSE에 관심 있다면 짝 프로젝트 격인 CUSE도 흥미로울 수 있음
  CUSE는 사용자 공간 문자 장치 드라이버 에뮬레이션으로, 새 커널 모듈을 컴파일하지 않고 하드웨어를 흉내 낼 수 있게 해줌
  최근 Python으로 IOCTL을 지원하는 하드웨어 장치를 작성하는 데 사용했음
  쉽게 동작하는 좋은 Python 라이브러리도 못 찾았고 문서도 부족했지만, 결국 ctypes FFI 라이브러리만으로 충분히 작성할 수 있었음
  커널 드라이버를 작성해 본 적 없는 입장에서 바로 직관적이지 않았던 유일한 부분은 IOCTL이 각 읽기/쓰기마다 버퍼 크기를 다시 맞춰야 해서 호출이 쌍으로 들어온다는 점이었음
  다행히 CUSE에는 입출력 바이트를 모두 보여주는 디버그 모드가 있음
  CUSE는 원래 사용자 공간 사운드 장치를 만들기 위해 구현됐지만¹ 커스텀 TTY 같은 용도에도 쓰였고, 나는 가상 SPI 장치를 만드는 데 사용했음
  누군가에게 유용하고 이 프로젝트가 더 주목받으면 좋겠음
  ¹ https://lwn.net/Articles/308445/

• 꽤 오래전에 dokuwiki라는 위키 시스템과 상호작용하기 위해 Python FUSE 파일시스템[1]을 만들었음
  hde llfuse[2] 위에 만들었는데, dokuwiki와 직접 관련 없는 저수준 API를 꽤 많이 구현해야 했음
  그래서 dokuwiki 구현과 무관한 부분을 감싸는 래퍼로 easyfuse[3][4]를 만들었고, FUSE 시스템을 만들 생각이라면 살펴볼 만함
  [1]: https://github.com/JelteF/dokuwikifuse
  [2]: https://pypi.org/project/llfuse/
  [3]: https://pypi.org/project/easyfuse/
  [4]: https://github.com/JelteF/easyfuse

  • dokuwiki용 FUSE를 만든 사용 사례가 무엇인지 궁금함
    기본적으로 dokuwiki는 텍스트 파일 묶음이니, NFS로 마운트하거나 Dropbox/Syncthing으로 공유하는 편이 더 단순하고 효율적이지 않을까?

• FUSE는 Makefile이 임의의 리소스 위에 방향 비순환 그래프를 지정할 수 있게 해주는 방식이라고 생각하면 좋음
  예를 들어 k8s 클러스터 상태를 노출하는 FUSE 파일시스템이 있으면, 나처럼 단순한 머리로도 접근 가능한 오퍼레이터를 작성하기 쉬워질 수 있음
  이메일도 마찬가지로, IMAP을 파일시스템으로 노출하면 RAG 앱(gpt4all 같은)이 모든 것에 직접 접근할 수 있지 않을까?

• 주제에서 벗어나지만, 90년대/2000년대 분위기의 블로그를 보면 항상 첫 게시물 페이지로 가봄
  gwolf.org도 포함해서, 그런 타임캡슐을 들여다보는 건 늘 실망시키지 않음