Python से FUSE फ़ाइल सिस्टम लिखने की गाइड शुरू

 (gwolf.org)
1 पॉइंट द्वारा GN⁺ 2024-10-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • क्लास के फ़ाइल सिस्टम प्रोजेक्ट और ChiPy प्रेज़ेंटेशन की तैयारी के साथ-साथ, Python में FUSE-आधारित फ़ाइल सिस्टम को चरण-दर-चरण बनाने वाली GitLab गाइड शुरू हुई
  • क्लास में इस्तेमाल होने वाला FIUnamFS एक toy फ़ाइल सिस्टम है, जिसमें contiguous file allocation, सब-डायरेक्टरी का समर्थन नहीं, और 1.44MB floppy disk size की सीमा है
  • छह semesters तक हर semester 30–40 छात्रों को असाइनमेंट दिया गया, लेकिन FUSE implementation जमा करने वाला सिर्फ एक छात्र था, इसलिए आसानी से follow की जा सकने वाली Python FUSE सामग्री की ज़रूरत बढ़ी
  • नई गाइड empty फ़ाइल सिस्टम से शुरू होकर system calls और features जोड़ने वाले incremental assignment फॉर्मेट में है, और RAM-based read/write तथा read-only passthrough implementation तक कवर करती है
  • DNS, Markdown on-the-fly compiling, unzip, और comments हटाने वाले फ़ाइल सिस्टम जैसे छोटे उदाहरण भी साथ हैं, ताकि छात्र practical examples से FUSE सीख सकें

क्लास प्रोजेक्ट से शुरू हुई Python FUSE गाइड

  • DebConf22 में Chicago Python User Group के presentation proposal मिलने के बाद, DebConf24 में फिर से बात उठी और Python presentation topic की तलाश शुरू हुई
  • वे Python को अपनी मुख्य भाषा नहीं मानते, लेकिन छात्र जिस भाषा को सबसे अच्छी तरह follow करते हैं, इसलिए क्लास में Python इस्तेमाल किया जाता है
  • क्लास प्रोजेक्ट FIUnamFS “Facultad de Ingeniería, Universidad Nacional Autónoma de México” का संक्षिप्त नाम है, और Mexico की National Autonomous University के engineering faculty की क्लास में इस्तेमाल होने वाला फ़ाइल सिस्टम है
    • यह contiguous file allocation पर आधारित है
    • subdirectories को support नहीं करता
    • आम तौर पर 1.44MB floppy disk size तक सीमित रहता है
    • specification और implementation में आसान toy फ़ाइल सिस्टम के रूप में इस्तेमाल होता है
  • छात्रों से simple menu की तुलना में अधिक refined interface बनाने की अपेक्षा की जाती रही है, और उपयोगकर्ता को बिना विशेष रूप से aware हुए FIUnamFS इस्तेमाल कराना हो तो FUSE उपयुक्त माना गया
  • यह प्रोजेक्ट छह semesters तक हर semester 30–40 छात्रों को दिया गया, लेकिन वास्तविक FUSE implementation जमा करने वाला छात्र सिर्फ एक था

मौजूदा सामग्री की सीमाएँ और विकल्प

GitLab गाइड की संरचना

  • नया GitLab project a hand-holding guide to writing FUSE-based filesystems in Python कई working FUSE filesystem implementations को चरण-दर-चरण दिखाता है
    • इनमें से कुछ RAM-based तरीके से चलते हैं
    • कुछ passthrough-based तरीके से implement किए गए हैं
    • FIUnamFS जैसी implementations के लिए pseudo block device आधारित फ़ाइल सिस्टम भी जोड़ने की योजना है
  • फिलहाल इसमें पांच incremental files हैं, जो सबसे सरल empty फ़ाइल सिस्टम से शुरू होकर system calls और features को एक-एक करके जोड़ती हैं
  • छात्रों को interesting लगने वाले छोटे और useful examples भी साथ में हैं
  • examples कुछ दर्जन lines के स्तर के हैं, इसलिए उन्हें क्लास में cover करना आसान है, और uncommentfs comments और whitespace को automatically हटा देता है

presentation schedule और public materials

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-13
Hacker News की राय

  • libfuse GitHub के [0] में C/C++ के उदाहरण complexity के हिसाब से अच्छी तरह व्यवस्थित हैं
    passthrough.c मौजूदा filesystem को mirror करता है, लेकिन इसमें लिखा है कि “performance भयानक है”, और passthrough_fh.c के बारे में कहा गया है कि “उतना खराब नहीं है”
    passthrough_ll.c low-level API से implement किया गया है और “तीनों में सबसे कम खराब” बताया गया है, जबकि passthrough_hp.cc C++ में लिखा high-performance version है
    जिन दिलचस्प FUSE projects को मैंने नोट किया है, उनमें बड़ी files को split करना [1], ZFS incremental snapshots को files के रूप में दिखाना [2], transparent filesystem compression [3], और archives को filesystem की तरह mount करने के options [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] अच्छा code example हो सकता है, लेकिन यह feature पहले से ZFS में built-in है
      हर dataset के mount point में एक hidden .zfs folder होता है, जो ls -A में भी नहीं दिखता; बस मानकर सीधे cd कर सकते हैं कि वह मौजूद है
      उसके नीचे snapshot folder होता है, और उसके अंदर उस dataset के हर snapshot का folder होता है, जिसमें snapshot की files होती हैं
      उदाहरण के लिए, zrepl_20241011_010143_000 snapshot की /etc/hosts file /.zfs/snapshot/zrepl_20241011_010143_000/etc/hosts में होती है
      अगर इस तरह का जादुई hidden behavior पसंद नहीं है, तो zfs set snapdir=visible से इसे normal folder की तरह दिखने के लिए set भी किया जा सकता है
    • कुछ समय पहले Linux में case sensitivity को bypass करने के उपयोग के लिए FUSE के बारे में सोच रहा था
      संबंधित links देखकर अच्छा लगा, और मेरी समझ थोड़ी जंग खा चुकी है, इसलिए अगर कोई FUSE tutorial या guide हो जो मददगार रही हो, तो पाना चाहूंगा

  • FUSE पसंद है, लेकिन यह अकेला विकल्प नहीं है; कुछ समय पहले 9p protocol से virtual filesystem implement करके देखा था और वह काफी मजेदार था
    याद पड़ता है कि मैंने py9p इस्तेमाल किया था, और Python experience fuse-python से काफी बेहतर था
    चाहें तो 9pfuse के जरिए 9p service को FUSE के माध्यम से mount कर सकते हैं, लेकिन मैंने kernel v9fs client इस्तेमाल किया था
    अगर मकसद बस network के पार filesystem deliver करना है, तो शायद मैंने diod 9p server इस्तेमाल किया था; कुल मिलाकर यह देखने लायक छोटा ecosystem है

    • 9p वाकई शानदार छोटा protocol है, और diod[0] में protocol की खुद की documentation भी काफी है और content भी simple है
      मेरे notes [1] पर हैं, लेकिन वे ज्यादातर original resources के links का collection हैं
      FUSE भी अच्छा है, लेकिन 9P ज्यादा general-purpose है, और Windows समेत कई जगहों पर इसकी अच्छी-quality implementations हैं
      हालांकि 9p की performance characteristics को लेकर मैं निश्चित नहीं हूं; इसे slow बताने वाली बातें देखी हैं, लेकिन definitive material नहीं मिला
      जानना चाहूंगा कि कोई benchmarks या जानकारी उपलब्ध है क्या
      [0]: https://github.com/chaos/diod/blob/master/protocol.md
      [1]: https://athenaeum.wiki/Zettelkasten/9p
    • करीब 18 महीने पहले HTTPS URL के आगे FUSE लगाने का एक experiment किया था
      मैं बड़ी file को पहले download किए बिना local file की तरह random read करना चाहता था
      जिन परेशानियों का सामना हुआ उनमें से एक यह थी कि FUSE का block size बहुत छोटा था, जिससे backend तक जाने वाली HTTP calls की latency और churn बढ़ गई, और काफी complex caching/read-ahead logic चाहिए पड़ा
      kernel का read-ahead logic बिल्कुल काम नहीं करता दिखा, और उस समय उसे guide करने का तरीका न मिलने के अलावा मैंने इस पर गहराई से जांच नहीं की
    • qemu में 9p(virtio-9p) की तुलना में fuse(virtiofs) इस्तेमाल करने पर performance बेहतर हो सकती है
      FAQ https://virtio-fs.gitlab.io पर देखा जा सकता है
    • py9p की आखिरी release 2013 में हुई थी और लगता है अभी भी “beta” के रूप में mark है
      फिर भी यह एक बढ़िया project है

  • काश एक महीने पहले, जब मुझे बिल्कुल यही प्रक्रिया अपनानी पड़ी थी, तब मुझे यह पता होता
    Jira को कम परेशान करने वाला बनाने की एक बेताब कोशिश में, मैंने अंदरूनी issue classification का उपयोग करके tree बनाने वाले jira-as-filesystem प्रोजेक्ट के बारे में सोचा था
    directories issues को, files issue fields को, और subdirectories linked issues को दर्शाएं—ऐसा रखा, और अंत में fuse-python चुना
    कुछ समय से उस पर काम नहीं कर पाया, लेकिन abstraction में पहले ही समस्या आ गई थी
    अगर directory name में केवल issue ID इस्तेमाल करें तो automation आसान है, लेकिन ls करने पर बस पहचानने में मुश्किल IDs की भरमार दिखती है और इंसानों के लिए browse करना कठिन हो जाता है, इसलिए मैंने issue ID के पीछे slugified summary जोड़ने वाला parallel -with-summary directory type जोड़ा

    • यह कोई अच्छा idea है, ऐसा नहीं कह रहा, लेकिन पूरे Jira environment का symbolic link version up-to-date रखने वाला daemon कैसा रहेगा?
      मूल files के लिए एक jira-as-filesystem हो, और इंसानों के browse व interaction के लिए उसी file को संबंधित कई locations पर कई links के रूप में रखने वाला symbolic link tree हो
      हो सकता है मेरी समझ कम हो और मैं जरूरत से ज्यादा layers जोड़ रहा हूं, लेकिन technically यह अभी बताए गए abstraction problem को हल कर सकता है
    • Unix filesystem में एक ही target को दो तरीकों से refer करना आम बात है
      आधुनिक Linux में disk को block device और UUID दोनों से refer किया जाता है, इसलिए मुझे यह approach ठीक और expectations के अनुरूप लगती है
      हालांकि निजी तौर पर JIRA खुद ही काफी complex है, इसलिए शायद मैं इसका इस्तेमाल नहीं करूंगा
    • GitHub पर jirafs family के काफी projects हैं
      उदाहरण: https://github.com/coddingtonbear/jirafs
    • क्या बस 1234-human-sense जैसा नहीं किया जा सकता?
      इसमें दोनों तरह की जानकारी है और parsing भी आसान लगती है
    • क्या बनाए गए solution को open source के रूप में release करने की संभावना है?

  • अलग-अलग trade-offs, performance और features वाले FUSE mount options वाकई बहुत हैं
    s3fs, goofys, seaweed, minio, Google Drive आदि भी हैं, और JuiceFS object storage को mount करके traditional filesystem में expected metadata के साथ POSIX-style access के लिए काफी दिलचस्प है
    https://juicefs.com

  • अच्छा है
    इससे जुड़ा सवाल: हाल में मैंने देखा है कि लोग ज्यादा व्यापक रूप से supported protocol होने के कारण NFS-based filesystem implement कर रहे हैं
    लगता है rclone Mac पर ऐसा करता है; क्या इस approach पर कोई guide या comparison material है?

    • मजेदार बात: recent macOS versions में macFUSE install करने के लिए security features बंद करने पड़ते हैं, लेकिन शानदार fuse-t मौजूद है
      यह लगभग replacement की तरह काम करता है, kernel extension की जरूरत नहीं होती, और background में NFS server खोलकर macOS feature से mount करता है
      performance भी काफी अच्छी है
    • Rust example: https://github.com/xetdata/nfsserve

  • अगर देखना चाहते हैं कि finished product कैसा दिखता है, तो virtual filesystem वाले music manager azuline/rosé को देखना अच्छा रहेगा
    comments, explanations, types और tests से भरपूर यह एक बढ़िया codebase है, इसलिए सीखना आसान होगा
    https://github.com/azuline/rose

  • अगर FUSE में रुचि है, तो इसका sibling project कहे जाने वाला CUSE भी दिलचस्प हो सकता है
    CUSE userspace character device driver emulation है, जो नया kernel module compile किए बिना hardware की नकल करने देता है
    हाल में मैंने Python में IOCTL support करने वाला hardware device लिखने के लिए इसका उपयोग किया
    आसानी से काम करने वाली अच्छी Python library भी नहीं मिली और documentation भी कम था, लेकिन अंत में केवल ctypes FFI library से ही इसे पर्याप्त रूप से लिख पाया
    kernel driver कभी न लिखने वाले व्यक्ति के तौर पर जो एकमात्र हिस्सा तुरंत intuitive नहीं था, वह यह था कि IOCTL को हर read/write के लिए buffer size फिर से match करना पड़ता है, इसलिए calls pair में आती हैं
    सौभाग्य से CUSE में debug mode है जो input/output bytes सभी दिखाता है
    CUSE मूल रूप से userspace sound device बनाने के लिए implement किया गया था¹, लेकिन custom TTY जैसे uses में भी इस्तेमाल हुआ है, और मैंने इसे virtual SPI device बनाने में इस्तेमाल किया
    उम्मीद है यह किसी के काम आए और इस project पर ज्यादा ध्यान जाए
    ¹ https://lwn.net/Articles/308445/

  • काफी समय पहले मैंने dokuwiki नाम के wiki system के साथ interact करने के लिए Python FUSE filesystem[1] बनाया था
    इसे hde llfuse[2] के ऊपर बनाया था, लेकिन dokuwiki से सीधे संबंधित न होने वाले low-level APIs का काफी हिस्सा implement करना पड़ा
    इसलिए dokuwiki implementation से असंबंधित हिस्सों को wrap करने वाले wrapper के रूप में easyfuse[3][4] बनाया, और अगर FUSE system बनाने का सोच रहे हैं तो देखने लायक है
    [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 बनाने का use case क्या था
      मूल रूप से dokuwiki text files का bundle है, तो क्या NFS से mount करना या Dropbox/Syncthing से share करना ज्यादा simple और efficient नहीं होगा?

  • FUSE को ऐसे समझना अच्छा है कि यह Makefile को arbitrary resources के ऊपर directed acyclic graph specify करने देता है
    उदाहरण के लिए, अगर k8s cluster state expose करने वाला FUSE filesystem हो, तो मेरे जैसे सीधे-सादे दिमाग के लिए भी approachable operator लिखना आसान हो सकता है
    email के साथ भी ऐसा ही है: अगर IMAP को filesystem के रूप में expose किया जाए, तो क्या RAG apps (gpt4all जैसे) हर चीज तक सीधे access नहीं कर पाएंगे?

  • विषय से अलग, लेकिन 90s/2000s vibe वाले blog देखते ही मैं हमेशा उसके पहले post page पर जाता हूं
    gwolf.org सहित, ऐसे time capsule में झांकना कभी निराश नहीं करता