2 पॉइंट द्वारा GN⁺ 2024-04-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें

MacBook Pro की स्टोरेज समस्या और recovery की विफलता

  • MacBook Pro की स्टोरेज पूरी तरह भर जाने से ऐसी स्थिति पैदा हुई जिसमें recovery संभव नहीं रही.
  • बच्चे ने Steam के जरिए गेम डाउनलोड करते हुए स्टोरेज पूरी भर दी.
  • macOS का startup volume इतना भर गया कि किसी भी तरीके से फाइलें delete नहीं की जा सकीं.

फाइल delete करने की कोशिश और restart की विफलता

  • Trash खाली करना, terminal commands, और Disk Utility का उपयोग करके फाइलें delete करने की सभी कोशिशें विफल रहीं.
  • restart के बाद Mac बिल्कुल भी boot नहीं हुआ.

Recovery OS और Time Machine backup restore करने की कोशिश

  • Recovery OS के जरिए Disk Utility repair और reinstall की कोशिश की गई, लेकिन वह भी विफल रही.
  • Time Machine backup के जरिए डेटा restore करने की कोशिश की गई, लेकिन version difference के कारण restore संभव नहीं हुआ.

बाहरी SSD का उपयोग कर फाइल copy और restore

  • network backup management Mac के जरिए Time Machine backup को बाहरी SSD पर copy किया गया.
  • ज़रूरी apps और files को सीधे MacBook Pro पर copy करके समस्या हल की गई.

GN⁺ की राय

  • यह लेख दिखाता है कि स्टोरेज समस्या के कारण Mac users किस तरह की चरम स्थिति का सामना कर सकते हैं और उससे निकलने की प्रक्रिया कैसी हो सकती है. इससे users को backup के महत्व और स्टोरेज management की ज़रूरत का एहसास हो सकता है.
  • लेख में बताई गई समस्या macOS की system limitations और bugs से जुड़ी हुई लगती है. यह इस बात पर ज़ोर देता है कि Apple को system stability और user experience बेहतर करने के लिए लगातार updates और patches देने चाहिए.
  • डेटा recovery के संदर्भ में, ऐसी स्थिति से बचने के लिए नियमित backup और cloud storage के उपयोग की सिफारिश की जाती है. साथ ही, users को compatibility problems से बचने के लिए operating system का latest version बनाए रखना चाहिए.
  • आलोचनात्मक नज़रिए से देखें तो यह लेख advanced users या experts नहीं होने वाले सामान्य users के लिए कुछ ज़्यादा technical और जटिल लग सकता है. यह user-friendly recovery options और बेहतर user support की ज़रूरत की ओर इशारा करता है.
  • यह लेख Mac users के लिए एक दिलचस्प case study पेश करता है और ऐसी ही समस्या आने पर काम आने वाली उपयोगी जानकारी देता है.

1 टिप्पणियां

 
GN⁺ 2024-04-05
Hacker News राय
  • बाहरी स्टोरेज डिवाइस का उपयोग करके Mac को बूट करना और आंतरिक डिस्क से अनावश्यक फ़ाइलें हटाना शायद बेहतर तरीका हो सकता था.

    • बाहरी स्टोरेज डिवाइस को Mac की startup disk के रूप में उपयोग करना: Apple सहायता लिंक
    • पता चला कि Apple Silicon आधारित Mac में सभी पोर्ट external boot के लिए एक जैसे काम नहीं करते.
      • MacBook: बाईं तरफ के पोर्ट्स में सबसे बाएँ वाले को छोड़कर USB-C पोर्ट का उपयोग करें
      • iMac: पीछे के पोर्ट्स में सबसे दाएँ वाले को छोड़कर USB-C पोर्ट का उपयोग करें
      • Mac mini: पीछे के पोर्ट्स में सबसे बाएँ वाले को छोड़कर USB-C पोर्ट का उपयोग करें
      • Mac Studio: पीछे के पोर्ट्स में सबसे दाएँ वाले को छोड़कर USB-C पोर्ट का उपयोग करें
      • Mac Pro (desktop): ऊपर के power button से सबसे दूर वाले USB-C पोर्ट को छोड़कर सभी पोर्ट्स का उपयोग करें
      • Mac Pro (rack): सामने के power button के सबसे पास वाले USB-C पोर्ट को छोड़कर सभी पोर्ट्स का उपयोग करें
  • HFS+ डिस्क संरचना के ज्ञान के आधार पर, अनुमान है कि journal फ़ाइल भर गई होगी, जिससे फ़ाइल delete करते समय अस्थायी रूप से और ज़्यादा space की ज़रूरत पड़ी होगी.

    • macOS ड्राइव पर सिर्फ 41K बचने तक फ़ाइलें लिखता रहता है.
    • NTFS और FAT32 में 0 bytes बचे होने पर भी फ़ाइलें delete की जा सकती थीं.
    • Sonoma ने SMB/Samba आधारित networking mount प्रक्रिया को तोड़ दिया, और अभी तक इसका समाधान नहीं मिला है.
  • SMB कुछ सालों से अविश्वसनीय और bug से भरा हो गया है, और Apple इस समस्या की परवाह करता नहीं दिखता.

    • चिंता है कि जिन लोगों के पास Mac का ज़्यादा अनुभव नहीं है, वे ऐसे system-level और chain-reaction failures का सामना होने पर कैसे निपटते होंगे.
  • अगर Mac का ज़्यादा अनुभव नहीं है, तो सबसे पहले fsck कमांड आज़मानी चाहिए.

    • जब ज़रूरी डिस्क डेटा को कहीं और कॉपी करके format करना और फिर वापस कॉपी करना संभव नहीं था, तब APFS दस्तावेज़ देखकर समाधान ढूँढा गया.
  • पहली नौकरी में इसी तरह की समस्या हुई थी. क्लस्टर को garbage files से भर दिया था, और rm कमांड काम नहीं कर रही थी.

    • सीखा कि फ़ाइल को shrink करना (cat /dev/null > foo), delete (rm foo) काम न करने पर भी काम कर सकता है.
  • Time Machine की विश्वसनीयता लगातार घटती लग रही है.

    • इसके विपरीत iOS/iPadOS backups हर बार ठीक से काम करते हैं.
  • ZFS 'slop space' का उपयोग करता है ताकि file system space की कमी से समस्या में न फँसे.

    • डिफ़ॉल्ट रूप से volume space का 3.2% reserve करता है (अधिकतम 128GB).
    • spa_slop_shift kernel tuning के ज़रिए अधिकतम 128GB अतिरिक्त space सुरक्षित किया जा सकता है.
  • यह विचार उलझाने वाला है कि फ़ाइल delete करने के लिए अस्थायी या स्थायी रूप से और ज़्यादा space की ज़रूरत पड़ सकती है.

    • snapshots, journaling आदि को सपोर्ट करने वाले आधुनिक file systems को deletion के लिए free space allocate करनी पड़ सकती है.
  • अक्टूबर 2018 में यह समस्या हुई थी.

    • अतिरिक्त APFS partition हटाकर disk space खाली किया गया.
  • iPhone पर भी ऐसा ही अनुभव हुआ.

    • डिस्क भर जाने पर deletion वास्तव में काम नहीं कर रही हो, ऐसा लगता है.
    • अनुमान है कि यह APFS के copy-on-write और snapshot support की वजह से होता है.
  • rm कमांड के fail होने की स्थिति से कभी निपटना नहीं पड़ा, लेकिन 256GB या उससे कम internal storage वाले आधुनिक Mac को manage करना असुविधाजनक है.

    • ज़रूरत पड़ने पर delete की जा सकने वाली लगभग 16GB की एक 'space holder' फ़ाइल रखी जाती है.
  • Linux system partition पर भी ऐसी ही स्थिति आई थी.

    • partition छोटा था, इसलिए updates जमा होने पर delete करने लायक space बहुत कम बचती थी.
    • आखिरकार partition को resize किया गया ताकि यह समस्या फिर न हो.