Python ile FUSE dosya sistemi yazma rehberi başlatıldı

 (gwolf.org)
1 puan yazan GN⁺ 2024-10-13 | 1 yorum | WhatsApp'ta paylaş
  • Ders amaçlı dosya sistemi projesi ile ChiPy sunum hazırlıkları kesişince, Python ile FUSE tabanlı dosya sistemini adım adım oluşturan bir GitLab rehberi başlatıldı
  • Derste kullanılan FIUnamFS, ardışık dosya ayırma kullanan, alt dizin desteği olmayan ve 1,44 MB disket boyutuyla sınırlı bir oyuncak dosya sistemi
  • Altı dönem boyunca her dönem 30-40 öğrenciye ödev verilmesine rağmen FUSE implementasyonu teslim eden yalnızca bir öğrenci olduğu için, takip etmesi kolay Python FUSE materyallerine duyulan ihtiyaç arttı
  • Yeni rehber, boş bir dosya sisteminden başlayıp sistem çağrılarını ve özellikleri ekleyen kademeli ödev biçiminde; RAM tabanlı okuma/yazma ve salt okunur passthrough implementasyonuna kadar konuları kapsıyor
  • DNS, Markdown’ın anında derlenmesi, unzip ve yorumları kaldıran dosya sistemi gibi kısa örnekler de yer alıyor; böylece öğrenciler pratik örneklerle FUSE öğrenebiliyor

Ders projesinden doğan Python FUSE rehberi

  • DebConf22’de Chicago Python User Group için sunum teklifi aldıktan sonra, DebConf24’te konu tekrar gündeme gelince Python sunumu için bir tema aranmaya başlandı
  • Python’u ana dil olarak görmese de, öğrencilerin en iyi takip edebildiği dil olduğu için derste Python kullanılıyor
  • Ders projesi olan FIUnamFS, “Facultad de Ingeniería, Universidad Nacional Autónoma de México”nun kısaltmasıdır ve Meksika Ulusal Özerk Üniversitesi Mühendislik Fakültesi derslerinde kullanılan bir dosya sistemidir
    • Ardışık dosya ayırma temel alınır
    • Alt dizinleri desteklemez
    • Genellikle 1,44 MB disket boyutuyla sınırlıdır
    • Belirtimi ve implementasyonu kolay bir oyuncak dosya sistemi olarak kullanılır
  • Öğrencilerden basit bir menüden daha rafine bir arayüz oluşturmaları istenmişti; kullanıcıların farkında olmadan FIUnamFS kullanabilmesi için FUSE’un uygun olduğu düşünüldü
  • Bu proje altı dönem boyunca dönem başına 30-40 öğrenciye verilmiş olsa da, gerçek bir FUSE implementasyonu teslim eden yalnızca bir öğrenci oldu

Mevcut materyallerin sınırları ve seçenekler

GitLab rehberinin yapısı

Sunum takvimi ve açık materyaller

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-13
Hacker News yorumları

  • libfuse GitHub’ındaki [0] içinde C/C++ için örnekler karmaşıklık düzeyine göre iyi düzenlenmiş
    passthrough.c mevcut dosya sistemini yansıtıyor ama “performansı berbat” deniyor; passthrough_fh.c içinse “o kadar kötü değil” denmiş
    passthrough_ll.c düşük seviyeli API ile uygulanmış ve “üçü arasında en az kötü olanı” deniyor; passthrough_hp.cc ise C++ ile yazılmış yüksek performanslı sürüm
    Not ettiğim ilginç FUSE projeleri arasında büyük dosyaları bölme [1], ZFS artımlı anlık görüntülerini dosya olarak gösterme [2], şeffaf dosya sistemi sıkıştırması [3], arşivleri dosya sistemi olarak mount etme seçenekleri [4], [5] var
    [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] iyi bir kod örneği olabilir, ama bu özellik zaten ZFS’in içinde yerleşik
      Her veri kümesinin mount noktasında ls -A ile bile görünmeyen gizli bir .zfs klasörü var; var olduğuna inanıp doğrudan cd etmeniz yeterli
      Onun altında snapshot klasörü bulunur; içinde de ilgili veri kümesinin her anlık görüntüsü için klasörler ve anlık görüntüdeki dosyalar yer alır
      Örneğin zrepl_20241011_010143_000 anlık görüntüsündeki /etc/hosts, /.zfs/snapshot/zrepl_20241011_010143_000/etc/hosts konumundadır
      Bu sihirli gizleme davranışını sevmiyorsanız zfs set snapdir=visible ile normal bir klasör gibi görünmesini de ayarlayabilirsiniz
    • Bir süre önce Linux’ta büyük/küçük harf duyarlılığını aşmak için FUSE kullanmayı düşünüyordum
      İlgili bağlantıları görmek güzel; bu konudaki sezgilerim biraz paslandı, faydasını gördüğünüz FUSE eğitimleri veya rehberleri varsa almak isterim

  • FUSE’u seviyorum ama tek seçenek değil; yakın zamanda 9p protokolü ile sanal bir dosya sistemi uygulamayı denedim ve epey eğlenceliydi
    Hatırladığım kadarıyla py9p kullandım ve Python deneyimi fuse-python’dan çok daha iyiydi
    İsterseniz 9pfuse ile 9p servisini FUSE üzerinden mount edebilirsiniz, ama ben kernel v9fs istemcisini kullandım
    Amacınız sadece dosya sistemini ağın ötesine taşımaksa sanırım diod 9p sunucusunu kullanmıştım; genel olarak göz atmaya değer küçük bir ekosistem

    • 9p gerçekten harika küçük bir protokol ve diod[0] içinde protokolün kendisiyle ilgili epey dokümantasyon var; içerik de basit
      Notlarım [1]’de, ama çoğu özgün kaynak bağlantılarından oluşan bir derleme
      FUSE da iyi ama 9P daha genel amaçlı; Windows dahil birçok yerde kaliteli uygulamaları var
      Yine de 9p’nin performans özelliklerinden emin değilim; yavaş olduğuna dair şeyler gördüm ama kesin bir kaynak görmedim
      Benchmark veya bilgi var mı merak ediyorum
      [0]: https://github.com/chaos/diod/blob/master/protocol.md
      [1]: https://athenaeum.wiki/Zettelkasten/9p
    • Yaklaşık 18 ay önce HTTPS URL’lerinin önüne FUSE koyma deneyi yapmıştım
      Büyük dosyaları önce indirmeden, yerel dosya gibi rastgele okumak istiyordum
      Yaşadığım sıkıntılardan biri FUSE’un blok boyutunun çok küçük olmasıydı; bu yüzden arka uca giden HTTP çağrılarında gecikme ve churn arttı, oldukça karmaşık bir önbellekleme/önceden okuma mantığı gerekti
      Kernel’in önceden okuma mantığı hiç çalışmıyor gibi görünüyordu; o dönemde onu yönlendirmenin yolunu bulamamam dışında konuyu derinlemesine araştırmadım
    • qemu’da 9p (virtio-9p) yerine fuse (virtiofs) kullanırsanız performans daha iyi olabilir
      FAQ’ye https://virtio-fs.gitlab.io adresinden bakabilirsiniz
    • py9p’nin son sürümü 2013’te çıkmış ve hâlâ “beta” olarak işaretli görünüyor
      Yine de harika bir proje

  • Bir ay önce tam olarak aynı süreçten geçmek zorunda kaldığımda bunu bilmiş olmayı isterdim
    Jira’yı daha az sinir bozucu şekilde kullanmaya yönelik çaresiz bir girişim olarak, dahili issue sınıflandırmasını kullanıp bir ağaç oluşturan jira-as-filesystem projesini düşündüm
    Dizinlerin issue’ları, dosyaların issue alanlarını, alt dizinlerin de bağlantılı issue’ları temsil etmesini sağladım ve sonunda fuse-python’ı seçtim
    Bir süredir üzerinde çalışamadım ama daha şimdiden soyutlamada sorun çıktı
    Dizin adı olarak yalnızca issue ID’sini kullanınca otomasyon kolaylaşıyor; fakat ls yaptığınızda yalnızca anlaşılması zor ID’lerden oluşan bir yığın gördüğünüz için insanların gezinmesi zorlaşıyor. Bu yüzden issue ID’sinin arkasına slug’laştırılmış özeti ekleyen paralel bir -with-summary dizin türü ekledim

    • İyi bir fikir demiyorum ama tüm Jira ortamının sembolik bağlantı sürümünü güncel tutan bir daemon nasıl olur diye düşündüm
      Orijinal dosyalar için bir jira-as-filesystem olur; insanların gezinip etkileşime girmesi içinse aynı dosyaları ilgili birçok konuma birden çok bağlantı olarak yerleştiren bir sembolik bağlantı ağacı kullanılır
      Yeterince anlamadığım için gereksiz yere fazladan katman ekliyor olabilirim, ama teknik olarak az önce bahsettiğin soyutlama sorununu çözebilir gibi görünüyor
    • Unix dosya sistemlerinde aynı hedefe iki yöntemle başvurmak yaygın bir şey
      Modern Linux’ta diskler hem blok aygıtı hem de UUID ile referanslandığı için bu yaklaşımın uygun ve beklentilere de uyduğunu düşünüyorum
      Yine de kişisel olarak JIRA’nın kendisi zaten yeterince karmaşık olduğu için kullanacağımı sanmıyorum
    • GitHub’da jirafs türevleri epey var
      Örnek: https://github.com/coddingtonbear/jirafs
    • Sadece 1234-human-sense gibi yapsan olmaz mı?
      İki tür bilgiyi de içeriyor ve ayrıştırması da kolay görünüyor
    • Yaptığın çözümü açık kaynak olarak yayımlama ihtimalin var mı?

  • FUSE mount seçenekleri gerçekten çok fazla; her birinin ödünleşimleri, performansı ve özellikleri farklı
    s3fs, goofys, seaweed, minio, Google Drive vb. de var; JuiceFS ise nesne depolamayı mount edip geleneksel bir dosya sisteminden beklenen metaverilerle POSIX tarzı erişim sağlamak için oldukça ilginç
    https://juicefs.com

  • Güzel
    Buna yakın bir soru olarak, son zamanlarda daha yaygın desteklenen bir protokol olduğu için NFS tabanlı dosya sistemleri uygulandığını görüyorum
    rclone Mac’te bunu yapıyor gibi; bu yaklaşıma dair bir rehber ya da karşılaştırma var mı?

    • İlginç bilgi: Güncel macOS sürümlerinde macFUSE kurmak için güvenlik özelliklerini kapatmak gerekiyor; ama harika bir fuse-t var
      Neredeyse bire bir alternatif gibi çalışıyor, kernel extension gerektirmiyor, arka planda bir NFS sunucusu açıp macOS özellikleriyle mount ediyor
      Performansı da oldukça iyi
    • Rust örneği: https://github.com/xetdata/nfsserve

  • Bitmiş ürünün nasıl göründüğünü görmek istiyorsanız, sanal dosya sistemi olan müzik yöneticisi azuline/rosé’ye bakabilirsiniz
    Çok sayıda yorum, açıklama, tip ve test içeren harika bir kod tabanı; öğrenmesi kolay olacaktır
    https://github.com/azuline/rose

  • FUSE ile ilgileniyorsanız, kardeş proje sayılabilecek CUSE da ilginizi çekebilir
    CUSE, kullanıcı alanında karakter aygıtı sürücüsü emülasyonudur; yeni bir kernel modülü derlemeden donanımı taklit etmenizi sağlar
    Yakın zamanda Python ile IOCTL destekleyen bir donanım aygıtı yazmak için kullandım
    Kolayca çalışan iyi bir Python kütüphanesi de bulamadım, dokümantasyon da yetersizdi; ama sonunda yalnızca ctypes FFI kütüphanesiyle yazmak yeterli oldu
    Kernel sürücüsü yazma deneyimi olmayan biri olarak hemen sezgisel gelmeyen tek kısım, IOCTL’ın her okuma/yazma için tampon boyutunu yeniden ayarlaması gerektiğinden çağrıların çiftler hâlinde gelmesiydi
    Neyse ki CUSE’ta tüm giriş/çıkış baytlarını gösteren bir debug modu var
    CUSE aslında kullanıcı alanında ses aygıtları oluşturmak için uygulanmıştı¹; ama özel TTY gibi amaçlarla da kullanıldı, ben de sanal bir SPI aygıtı yapmak için kullandım
    Birilerine faydalı olmasını ve bu projenin daha çok ilgi görmesini isterim
    ¹ https://lwn.net/Articles/308445/

  • Epey uzun zaman önce dokuwiki adlı wiki sistemiyle etkileşim kurmak için Python FUSE dosya sistemi[1] yazmıştım
    hde llfuse[2] üzerine kurmuştum; dokuwiki ile doğrudan ilgili olmayan oldukça fazla düşük seviyeli API uygulamam gerekti
    Bu yüzden dokuwiki uygulamasından bağımsız kısımları saran bir wrapper olarak easyfuse[3][4]’ü yaptım; FUSE sistemi yapmayı düşünüyorsanız göz atmaya değer
    [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 için FUSE yapmanın kullanım senaryosunu merak ediyorum
      Sonuçta dokuwiki temelde bir metin dosyaları kümesi; NFS ile mount etmek ya da Dropbox/Syncthing ile paylaşmak daha basit ve verimli olmaz mı?

  • FUSE’u, Makefile’ın keyfî kaynaklar üzerinde yönlü döngüsüz grafik tanımlayabilmesini sağlayan bir yöntem gibi düşünebilirsiniz
    Örneğin k8s kümesinin durumunu açığa çıkaran bir FUSE dosya sistemi varsa, benim gibi basit düşünen biri için bile erişilebilir operatörler yazmak kolaylaşabilir
    E-posta için de benzer şekilde, IMAP’i dosya sistemi olarak açığa çıkarırsanız RAG uygulamaları (gpt4all gibi) her şeye doğrudan erişemez mi?

  • Konu dışı ama 90’lar/2000’ler havasındaki blogları görünce her zaman ilk gönderi sayfasına giderim
    gwolf.org da dâhil; böyle zaman kapsüllerine bakmak hiçbir zaman hayal kırıklığına uğratmıyor