Panduan Menulis Sistem Berkas FUSE dengan Python Dimulai

 (gwolf.org)
1 poin oleh GN⁺ 2024-10-13 | 1 komentar | Bagikan ke WhatsApp
  • Bertepatan dengan proyek sistem berkas untuk kelas dan persiapan presentasi ChiPy, sebuah panduan GitLab untuk membuat sistem berkas berbasis FUSE dengan Python secara bertahap telah dimulai
  • FIUnamFS yang digunakan di kelas adalah sistem berkas mainan dengan alokasi berkas kontigu, tanpa dukungan subdirektori, dan dibatasi pada ukuran disket 1,44 MB
  • Selama enam semester, tugas ini diberikan kepada 30–40 mahasiswa per semester, tetapi hanya satu orang yang mengumpulkan implementasi FUSE, sehingga kebutuhan akan materi Python FUSE yang mudah diikuti makin besar
  • Panduan baru ini berbentuk tugas bertahap yang dimulai dari sistem berkas kosong lalu menambahkan system call dan fitur, mencakup baca/tulis berbasis RAM hingga implementasi passthrough hanya-baca
  • Disertakan juga contoh singkat seperti DNS, kompilasi Markdown secara langsung, unzip, dan sistem berkas penghapus komentar, sehingga mahasiswa dapat mempelajari FUSE lewat contoh praktis

Panduan Python FUSE yang Berawal dari Proyek Kelas

  • Setelah menerima usulan presentasi dari Chicago Python User Group di DebConf22, topik itu dibahas lagi di DebConf24, sehingga penulis mencari topik presentasi Python
  • Meski Python tidak dianggap sebagai bahasa utama, Python digunakan di kelas karena merupakan bahasa yang paling mudah diikuti mahasiswa
  • Proyek kelas FIUnamFS adalah singkatan dari “Facultad de Ingeniería, Universidad Nacional Autónoma de México”, yaitu sistem berkas yang digunakan dalam kelas di Fakultas Teknik Universitas Otonom Nasional Meksiko
    • Berbasis alokasi berkas kontigu
    • Tidak mendukung subdirektori
    • Biasanya dibatasi pada ukuran disket 1,44 MB
    • Digunakan sebagai sistem berkas mainan yang mudah dispesifikasikan dan diimplementasikan
  • Mahasiswa selama ini diminta membuat antarmuka yang lebih rapi daripada menu sederhana, dan FUSE dianggap cocok agar pengguna dapat memakai FIUnamFS tanpa menyadarinya
  • Proyek ini telah diberikan selama enam semester kepada 30–40 mahasiswa per semester, tetapi hanya satu mahasiswa yang benar-benar mengumpulkan implementasi FUSE

Keterbatasan Materi yang Ada dan Pilihan yang Tersedia

Struktur Panduan GitLab

Jadwal Presentasi dan Materi Publik

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-13
Komentar Hacker News

  • Di GitHub libfuse [0], contoh untuk C/C++ tersusun rapi berdasarkan tingkat kompleksitas
    passthrough.c memirrorkan filesystem yang ada, tetapi disebut “performanya buruk sekali”, sementara passthrough_fh.c disebut “tidak seburuk itu”
    passthrough_ll.c diimplementasikan dengan API low-level dan disebut “yang paling tidak buruk dari ketiganya”, sedangkan passthrough_hp.cc adalah versi berkinerja tinggi yang ditulis dalam C++
    Beberapa proyek FUSE menarik yang pernah saya catat antara lain pemecahan file berukuran besar [1], menampilkan snapshot inkremental ZFS sebagai file [2], kompresi filesystem transparan [3], serta opsi untuk me-mount arsip sebagai filesystem [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] mungkin bisa menjadi contoh kode yang bagus, tetapi fitur ini sebenarnya sudah tertanam di ZFS
      Di titik mount setiap dataset ada folder tersembunyi .zfs yang bahkan tidak terlihat dengan ls -A; cukup percaya bahwa folder itu ada lalu langsung cd ke sana
      Di bawahnya ada folder snapshot, dan di dalamnya ada folder untuk tiap snapshot dataset tersebut, berisi file-file snapshot
      Misalnya /etc/hosts dari snapshot zrepl_20241011_010143_000 ada di /.zfs/snapshot/zrepl_20241011_010143_000/etc/hosts
      Jika tidak suka perilaku tersembunyi yang terasa ajaib seperti ini, Anda juga bisa mengaturnya agar terlihat seperti folder biasa dengan zfs set snapdir=visible
    • Beberapa waktu lalu saya sempat terpikir memakai FUSE untuk kebutuhan mengakali sensitivitas huruf besar/kecil di Linux
      Senang melihat tautan-tautan terkait ini, dan karena insting saya sudah agak berkarat, saya akan senang menerima tutorial atau panduan FUSE yang pernah membantu

  • Saya suka FUSE, tetapi itu bukan satu-satunya pilihan; beberapa waktu lalu saya mencoba mengimplementasikan filesystem virtual dengan protokol 9p, dan itu cukup menyenangkan
    Seingat saya saya memakai py9p, dan pengalaman dengan Python jauh lebih baik dibanding fuse-python
    Jika mau, layanan 9p bisa di-mount melalui FUSE dengan 9pfuse, tetapi saya memakai klien v9fs kernel
    Kalau tujuannya sekadar meneruskan filesystem lewat jaringan, rasanya saya pernah memakai server 9p diod; secara keseluruhan ini ekosistem kecil yang layak dilihat-lihat

    • 9p benar-benar protokol kecil yang bagus, dan diod[0] juga punya cukup banyak dokumentasi tentang protokol itu sendiri, dengan isi yang sederhana
      Catatan saya ada di [1], tetapi sebagian besar hanya kumpulan tautan ke materi asli
      FUSE juga bagus, tetapi 9P lebih serbaguna, dan ada implementasi berkualitas baik di banyak tempat, termasuk Windows
      Namun saya tidak yakin dengan karakteristik performa 9p; saya pernah melihat cerita bahwa ia lambat, tetapi belum melihat materi yang konklusif
      Saya penasaran apakah ada benchmark atau informasi tentang itu
      [0]: https://github.com/chaos/diod/blob/master/protocol.md
      [1]: https://athenaeum.wiki/Zettelkasten/9p
    • Sekitar 18 bulan lalu saya bereksperimen menaruh FUSE di depan URL HTTPS
      Saya ingin bisa membaca secara acak seperti file lokal tanpa mengunduh file besar terlebih dahulu
      Salah satu rasa sakit yang saya alami adalah ukuran blok FUSE terlalu kecil, sehingga latensi dan churn panggilan HTTP ke backend menjadi besar, dan diperlukan logika caching/prefetch yang cukup rumit
      Logika readahead kernel tampaknya sama sekali tidak bekerja, dan saat itu saya tidak menyelidikinya lebih dalam selain tidak berhasil menemukan cara untuk mengarahkannya
    • Di qemu, memakai fuse(virtiofs) bisa memberikan performa lebih baik daripada 9p(virtio-9p)
      FAQ bisa dilihat di https://virtio-fs.gitlab.io
    • Rilis terakhir py9p adalah tahun 2013 dan tampaknya masih ditandai sebagai “beta”
      Meski begitu, itu proyek yang keren

  • Andaikan saya tahu ini sebulan lalu, saat saya harus melalui proses yang persis sama
    Dalam upaya nekat agar Jira tidak terlalu menyebalkan untuk dipakai, saya terpikir membuat proyek jira-as-filesystem yang membangun tree menggunakan klasifikasi issue internal
    Direktori merepresentasikan issue, file merepresentasikan field issue, dan subdirektori merepresentasikan issue yang tertaut; akhirnya saya memilih fuse-python
    Saya belum sempat mengerjakannya lagi untuk sementara, tetapi abstraksinya sudah mulai bermasalah
    Kalau nama direktori hanya memakai ID issue, otomatisasi jadi mudah, tetapi saat menjalankan ls, yang terlihat hanya deretan ID yang sulit dikenali sehingga susah dijelajahi manusia; karena itu saya menambahkan tipe direktori paralel -with-summary yang menambahkan ringkasan yang diubah menjadi slug setelah ID issue

    • Bukan berarti ini ide bagus, tapi bagaimana kalau ada daemon yang menjaga versi symbolic link dari seluruh lingkungan Jira tetap mutakhir?
      Caranya, satu jira-as-filesystem untuk file asli, lalu untuk dijelajahi dan digunakan manusia ada tree symbolic link yang menempatkan file yang sama sebagai beberapa link di berbagai lokasi terkait
      Bisa saja ini menambahkan lapisan yang tidak perlu karena pemahaman saya kurang, tetapi secara teknis tampaknya bisa menyelesaikan masalah abstraksi yang disebutkan tadi
    • Di filesystem Unix, merujuk target yang sama dengan dua cara itu hal yang umum
      Di Linux modern, disk dirujuk baik sebagai block device maupun UUID, jadi menurut saya pendekatan ini masuk akal dan sesuai ekspektasi
      Namun secara pribadi, JIRA sendiri sudah cukup kompleks sehingga sepertinya saya tidak akan memakainya
    • Di GitHub ada cukup banyak keluarga jirafs
      Contoh: https://github.com/coddingtonbear/jirafs
    • Tidak bisakah cukup dibuat seperti 1234-human-sense?
      Itu memuat kedua jenis informasi dan tampaknya mudah di-parse
    • Apakah ada kemungkinan solusi yang dibuat akan dirilis sebagai open source?

  • Ada sangat banyak opsi mount FUSE dengan kompromi, performa, dan fitur yang berbeda-beda
    Ada juga s3fs, goofys, seaweed, minio, Google Drive, dan JuiceFS cukup menarik untuk penggunaan memasang object storage lalu mengaksesnya dengan cara POSIX yang memiliki metadata seperti yang diharapkan dari filesystem tradisional
    https://juicefs.com

  • Bagus
    Sebagai pertanyaan yang berdekatan, belakangan saya melihat ada yang mengimplementasikan filesystem berbasis NFS karena itu protokol yang lebih luas didukung
    Sepertinya rclone melakukan ini di Mac; adakah panduan atau materi perbandingan tentang pendekatan ini?

    • Fakta menarik: pada versi macOS terbaru, untuk memasang macFUSE Anda harus mematikan fitur keamanan, tetapi ada fuse-t yang hebat
      Ia bekerja hampir seperti pengganti, tidak memerlukan kernel extension, membuka server NFS di latar belakang, lalu me-mount dengan fitur macOS
      Performanya juga cukup bagus
    • Contoh Rust: https://github.com/xetdata/nfsserve

  • Jika ingin melihat seperti apa produk yang sudah jadi, lihat manajer musik azuline/rosé yang memiliki filesystem virtual
    Codebase-nya bagus, dengan banyak komentar, penjelasan, tipe, dan test, jadi mudah dipelajari
    https://github.com/azuline/rose

  • Jika tertarik pada FUSE, proyek pasangannya, CUSE, juga mungkin menarik
    CUSE adalah emulasi driver character device di user space, yang memungkinkan meniru hardware tanpa mengompilasi modul kernel baru
    Baru-baru ini saya menggunakannya untuk menulis perangkat hardware yang mendukung IOCTL dengan Python
    Saya tidak menemukan library Python yang bagus dan mudah dipakai, dokumentasinya juga kurang, tetapi akhirnya ternyata cukup bisa dibuat hanya dengan library FFI ctypes
    Sebagai orang yang belum pernah menulis driver kernel, satu-satunya bagian yang tidak langsung intuitif adalah bahwa IOCTL harus menyesuaikan ulang ukuran buffer pada tiap read/write, sehingga panggilannya datang berpasangan
    Untungnya CUSE punya mode debug yang menampilkan semua byte input/output
    CUSE awalnya diimplementasikan untuk membuat perangkat suara di user space¹, tetapi juga pernah dipakai untuk hal seperti TTY kustom, dan saya menggunakannya untuk membuat perangkat SPI virtual
    Semoga ini berguna bagi seseorang dan proyek ini mendapat lebih banyak perhatian
    ¹ https://lwn.net/Articles/308445/

  • Cukup lama lalu saya membuat filesystem FUSE Python[1] untuk berinteraksi dengan sistem wiki bernama dokuwiki
    Itu dibuat di atas hde llfuse[2], tetapi saya harus mengimplementasikan cukup banyak API level rendah yang tidak terkait langsung dengan dokuwiki
    Karena itu saya membuat easyfuse[3][4] sebagai wrapper yang membungkus bagian-bagian yang tidak bergantung pada implementasi dokuwiki, dan layak dilihat jika Anda berencana membuat sistem 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

    • Saya penasaran apa use case membuat FUSE untuk dokuwiki
      Pada dasarnya dokuwiki adalah kumpulan file teks, jadi bukankah me-mount-nya lewat NFS atau membagikannya lewat Dropbox/Syncthing akan lebih sederhana dan efisien?

  • FUSE bisa dianggap sebagai cara yang memungkinkan Makefile menentukan directed acyclic graph di atas resource arbitrer
    Misalnya, jika ada filesystem FUSE yang mengekspos status cluster k8s, akan lebih mudah menulis operator yang bisa diakses bahkan oleh orang berpikiran sederhana seperti saya
    Email juga sama; jika IMAP diekspos sebagai filesystem, bukankah aplikasi RAG (seperti gpt4all) bisa mengakses semuanya secara langsung?

  • Sedikit keluar topik, tetapi saat melihat blog bernuansa 90-an/2000-an, saya selalu membuka halaman posting pertama
    Termasuk gwolf.org; mengintip kapsul waktu seperti itu selalu tidak mengecewakan