हार्ड ड्राइव हमेशा भरी क्यों रहती है

 (marginalia.nu)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्टोरेज क्षमता कई बार बढ़ाने के बाद भी इस्तेमाल साथ-साथ बढ़ता रहा, और 81 लोगों वाले Mastodon पोल में भी करीब आधे लोग अपनी डिस्क का 75% से ज़्यादा इस्तेमाल कर रहे थे
  • इसे कुछ हद तक entropy logic से समझाया जा सकता है कि खाली स्थिति की तुलना में भरी हुई स्थिति तक पहुंचने के तरीके ज़्यादा होते हैं, लेकिन यह user behavior को पूरी तरह नहीं समझाता
  • सीमा तक पहुंचने से पहले सफाई टालना और फिर तत्काल जरूरत जितना ही हटाना डिस्क को लगातार saturation की स्थिति में रखता है
  • धीमा हुआ software, जमा technical debt, भीड़भाड़ वाली सड़कें और तंग schedules भी वही pattern दिखाते हैं कि दर्द threshold तक पहुंचने के बाद ही प्रतिक्रिया दी जाती है
  • कुल resources से छोटी artificial constraint को budget की तरह सेट करने से premature optimization से बचते हुए भी समस्या को सीमा तक अनदेखा नहीं करना पड़ता

स्टोरेज space लगातार भरता क्यों रहता है

  • root drive में उपलब्ध 0.47TB में से सिर्फ 17GB बचा है, यानी free space 3% है, और अलग से लगाई गई 12TB drive में भी 140GB, करीब 1% ही बचा है
  • स्टोरेज space 1990 के दशक के करीब 80MB से बढ़कर कई बार दोगुना होते हुए दर्जनों TB तक पहुंच गया, लेकिन फिर भी उसका अधिकांश हिस्सा इस्तेमाल में है
    • साफ करने योग्य files ढूंढने वाला software बहुत पहले से मौजूद है, यह भी दिखाता है कि यह समस्या लगातार बनी रही है
  • Mastodon poll के 81 respondents में से करीब आधे अपनी hard drive का 75% से ज़्यादा इस्तेमाल कर रहे थे, इसलिए storage के खाली होने की बजाय भरे रहने के मामले आम थे
  • खाली disk की तुलना में भरी disk बनाने वाली states ज्यादा होती हैं, इसलिए storage amount को ध्यान में रखे बिना state को random तरीके से बदलें तो वह saturation की ओर जाती है—ऐसी entropy-based interpretation संभव है
  • लेकिन disk तब तक समस्या नहीं लगती जब तक उसमें और store करना संभव न रहे, और उस समय तक वह इतनी बिखर चुकी होती है कि हर file को delete करना है या नहीं, यह तय करना मुश्किल हो जाता है
    • user केवल इतना साफ करता है कि थोड़ा समय मिल जाए, फिर रुक जाता है, इसलिए disk जल्दी ही फिर सीमा पर पहुंच जाती है
    • storage capacity को कई orders of magnitude तक बढ़ा देने पर भी यह behavior नहीं बदलता

दर्द की threshold और artificial constraints

  • समस्या के असहनीय स्तर तक पहुंचने तक response टालने का pattern कई क्षेत्रों में दोहराया जाता है
    • software को तब तक optimize नहीं किया जाता जब तक वह बहुत धीमा न हो जाए, इसलिए वह आम तौर पर लगातार धीमा ही रहता है
    • technical debt तब तक जमा होता है जब तक code पर काम करना दर्दनाक न हो जाए और refactoring अपरिहार्य न हो जाए
      • कम अनुभवी developers तो बिल्कुल नए सिरे से शुरू भी कर देते हैं, इसलिए ज्यादातर codebases अव्यवस्थित हो जाते हैं
    • road networks का विस्तार तभी किया जाता है जब congestion संभालना मुश्किल हो जाए
    • diet को तब तक manage नहीं किया जाता जब तक बड़े pants खरीदने की जरूरत न पड़ जाए
    • full-time job छोड़कर self-employed बन जाने और obligations व instructions खत्म हो जाने के बाद भी schedule पहले जितना, कभी-कभी उससे भी ज्यादा व्यस्त भर जाता है
  • अगर threshold तक इंतजार किया जाए तो चलते-चलते थोड़ा-थोड़ा हल करने की तुलना में संभालने वाला काम बहुत बड़ा हो जाता है, लेकिन उलटकर premature optimization भी desirable नहीं है
  • दोनों समस्याओं को balance करने के लिए Jevons paradox का उपयोग करते हुए कुल available resources से छोटी practical constraint रखी जा सकती है, और उसी दायरे में optimize किया जा सकता है
    • personal finance में इसे budget कहा जाता है, लेकिन दूसरे क्षेत्रों में यही principle बार-बार अनदेखा होता है
    • Raspberry Pi पर software deploy करके खुद इस्तेमाल करते हुए optimize करें तो वह Threadripper पर भी तेज चलेगा
    • 80×25 terminal के Vim में navigate हो सकने वाला codebase शक्तिशाली modern IDE में भी navigate किया जा सकता है
  • resources और features बढ़ने पर लगता है कि ज्यादा काम किया जा सकेगा, लेकिन असल में वे कभी-कभी वही काम ज्यादा cost पर करवाते हैं

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय
  • जब cross-platform desktop software बनाया जाता है, तो समस्या के सीमा तक पहुँचने से पहले उसे हल करना कहीं ज़्यादा आसान होता है। इसलिए हमने यह सिद्धांत अपनाया कि पहले Git commit से ही Windows, Mac, Linux पर हमेशा build और run होना चाहिए
    यह एक काफ़ी तकलीफ़देह constraint था, लेकिन इसने customer support requests की एक पूरी category ही ख़त्म कर दी। प्रतियोगी कभी सिर्फ Mac और Linux support करते हैं, या सिर्फ Windows रिलीज़ करके बाद में UNIX support का वादा करते हैं, और users के लगातार आने वाले “Linux कब?” जैसे सवालों से उन्हें जूझते देखकर राहत मिलती है। अब भी “BSD porting कब?” जैसे सवाल आते हैं, लेकिन वह संभालने लायक स्तर पर है
    • लगता है कि BSD porting माँगने वाले लोग ख़ुद मदद के लिए आगे आने की संभावना भी असामान्य रूप से ज़्यादा रखते होंगे; क्या यह सही है?
  • अगर कोई software Raspberry Pi पर deploy करके ख़ुद इस्तेमाल किया गया है, तो उसके Threadripper पर भी तेज़ चलने वाली बात से मैं पूरी तरह सहमत हूँ। branch prediction, memory access latency, inlining जैसी modern CPU को ध्यान में रखकर की गई low-level optimization पिछले 15~20 सालों में आए लगभग हर CPU पर असरदार रही है
    नए SIMD instructions भी दिलचस्प हैं, लेकिन मैं हर optimization का baseline 2015 MacBook Pro के Intel Haswell और AVX2 को मानता हूँ। जो code उस environment में अच्छा चलता है, वह आज भी उतना ही अच्छा चलता है
  • दिलचस्प नज़रिया है। मैं इस समय 1TB disk का 97% इस्तेमाल कर रहा हूँ
    हर बार जब 256GB से 512GB तक बढ़ा, तो साथ में store किया जाने वाला content भी बढ़ गया। clone करने के लिए repositories, download करने के लिए music, archive करने के लिए YouTube videos और movies अंतहीन हैं, और 720p से 1080p और 4K पर जाने के साथ file sizes भी बढ़ती गईं। games भी इतने बड़े होते जा रहे हैं कि किसी दूसरी Steam game को install करने के लिए एक को delete करना पड़ता है। आख़िरकार क्या यह बस इतना ही है कि जब तक बड़ा टोकरा न मिले, आदमी मौजूदा टोकरे को जितना हो सके भरता रहता है?
    • यहाँ repositories को clone करने का मतलब क्या सिर्फ offline archive या bookmark के लिए है, या software install process में इसकी ज़रूरत पड़ती है?
      मैं अपनी पसंद की repositories को GitHub या Codeberg आदि पर star कर देता हूँ। उम्मीद है कि कभी fediverse की तरह अलग-अलग Git forges के बीच भी stars share किए जा सकेंगे, ताकि GitHub, GitLab, Codeberg सब पर अलग account बनाए रखने की ज़रूरत न पड़े। मैं जानना चाहता हूँ कि क्या आप इस डर से code को सीधे clone करके रखते हैं कि repository गायब हो सकती है या inaccessible हो सकती है
  • /nix partition लगभग हमेशा 90% से ज़्यादा भरा रहता है, सिवाय उस समय के जब बिलकुल नया install किया गया हो। Nix साफ़ तौर पर developer के उस नज़रिए को दिखाता है कि disk को garbage collection से तभी reclaim किया जाए जब space की सच में ज़रूरत हो, कुछ वैसे ही जैसे memory management में होता है। कई versions के intermediate build artifacts भी बहुत ज़्यादा जगह घेरते हैं
    media server भरा नहीं रहता, क्योंकि मैं कई सालों में धीरे-धीरे बढ़ने वाला heterogeneous RAID इस्तेमाल करता हूँ, जहाँ पुरानी drive ख़राब होने पर उसे लगभग उसी क़ीमत की लेकिन बड़ी drive से बदल देता हूँ। घर के सारे CD और DVD को digitize करने की कोशिश भी मैंने छोड़ दी। lossless compression वाले audio CD और Wii games की कुछ value है, लेकिन HD-DVD बिल्कुल भी मेहनत के लायक नहीं है
    • क्या CD और DVD पहले से ही digital media नहीं हैं?
  • मैं rootfs को tmpfs पर चलाता हूँ। persistent storage के लिए hard drive लगभग खाली रहती है, लेकिन tmpfs किसी समझ में न आने वाले तरीके से लगातार बिखरता जाता है। जब RAM कम पड़ने लगती है, तो temporary space वापस पाने के लिए system restart कर देता हूँ
    यह सुनिश्चित करना कि क़ीमती data गायब न हो, इसलिए आम तौर पर उसे Nix में लिखना और Git इस्तेमाल करने वाले project folders में सुरक्षित रखना, काफ़ी झंझट भरा है। इस तरह की time machine जैसी setup को सालों तक बनाए रखने में बहुत मेहनत लगी, लेकिन लगातार बढ़ते scale और complexity को संभालने का यही एकमात्र तरीका लगता है
  • Parkinson's Law याद आती है। इसका मतलब है, “काम उतना फैलता है जितना समय उसे पूरा करने के लिए उपलब्ध हो”
  • लगता है आपको बहुत किनारे पर जीना पसंद नहीं है। सुखी जीवन वह है जिसमें इंसान व्यस्त तो हो, लेकिन भाग-दौड़ में पिसा न हो; software उतना ही fast हो जितनी ज़रूरत है; पैसे और ज़रूरत के बीच संतुलन बना रहे; और hard drive में ठीक-ठाक खाली जगह बची रहे