इतनी भर चुकी डिस्क कि उसे बहाल भी नहीं किया जा सका

 (sixcolors.com)
2 पॉइंट द्वारा GN⁺ 2024-04-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • M2 MacBook Pro का startup volume Steam गेम डाउनलोड के दौरान इतना भर गया कि केवल 41KB बचा, और macOS ऐसी स्थिति में पहुंच गया जहां वह फाइलें delete भी नहीं कर पा रहा था
  • Finder में Trash खाली करना, Terminal के rm और find -exec rm, यहां तक कि Disk Utility से Time Machine snapshot delete करना भी “No space left on device” जैसे errors के साथ विफल रहा
  • restart के बाद booting भी बीच में अटक गई, और recoveryOS तथा Apple silicon के Share Disk से दूसरे Mac पर mount करने पर भी deletion को force नहीं किया जा सका
  • drive erase करने और macOS reinstall के बाद Time Machine restore की कोशिश की गई, लेकिन Ventura restore रुक गया, Sonoma 14.4 और पुराने 14.3.1 के version difference की दिक्कत आई, और SMB/Samba network mount भी विफल रहा
  • आखिरकार नवीनतम Time Machine disk image को external 1TB SSD पर कॉपी करके home directory की files और apps को manually recover किया गया; storage exhaustion और backup restore failure एक साथ हो जाएं तो अनुभवी उपयोगकर्ताओं के लिए भी संभालना मुश्किल हो जाता है

स्टोरेज भर जाने से delete भी नहीं कर पाया Mac

  • M2 MacBook Pro की storage Steam पर कानूनी रूप से खरीदे गए गेम डाउनलोड करते समय भर गई
  • macOS ने drive खतरनाक रूप से भर जाने के बावजूद बड़े Steam download को नहीं रोका, और startup volume में केवल 41KB बचा
  • ज्यादातर महत्वपूर्ण फाइलें cloud में थीं, और local की बड़ी फाइलों को हर हाल में बचाना जरूरी नहीं था
  • समस्या सिर्फ capacity की कमी नहीं थी, बल्कि यह थी कि operating system किसी भी तरीके से files delete नहीं कर पा रहा था

संदिग्ध कारण: Steam download और local Time Machine snapshots

  • gigabit internet connection और बड़े Steam files की वजह से संभव है कि macOS storage growth को नियंत्रित नहीं कर पाया हो
  • साथ ही, यह भी शक था कि macOS local Time Machine snapshots बना रहा था
  • macOS external या network Time Machine destination पर backup लेते समय भी पिछले 24 घंटे का local backup देने के लिए snapshots बनाए रखता है
  • Steam files ऊपर से एक बहुत बड़ी single file जैसी दिख रही थीं, लेकिन Time Machine के नजरिए से संभव है उन्हें अलग तरह से handle किया गया हो
  • local की actual files और विशेष रूप से बने snapshots में टकराव हुआ हो सकता है, लेकिन सटीक कारण की पुष्टि नहीं हुई

delete करने की सभी कोशिशें नाकाम

  • Finder Trash खाली करना File > Empty Trash से विफल रहा
    • error message था: “The operation can’t be completed because the disk is full”
  • Terminal चल रहा था, लेकिन standard Unix rm command काम नहीं कर रही थी
    • error message था: “No space left on device”
    • बड़ी files खोजकर -exec option के साथ rm चलाने वाला find-आधारित विकल्प भी विफल रहा
  • Disk Utility में भी APFS startup volume के Time Machine snapshots चुनकर delete करने की कोशिश की गई, लेकिन वही सीमा सामने आई
    • सामान्यतः snapshots केवल पिछले snapshots से अंतर के लिए जरूरी storage space लेते हैं
    • इस मामले में भी “no space left” error आया

restart, recoveryOS और Share Disk भी काम नहीं आए

  • cache cleanup की उम्मीद में restart किया गया, लेकिन Mac अब सामान्य रूप से boot नहीं हुआ
  • progress bar लगभग आधे तक जाने के बाद बार-बार fail हो रही थी
  • recoveryOS में startup volume unmounted होने की स्थिति में Disk Utility repair और reinstall से जुड़े काम किए गए, लेकिन Terminal commands ने वही error दिया
  • Apple silicon की Share Disk सुविधा से उस drive को दूसरे Mac पर mount करने की कोशिश की गई
    • Samba-आधारित disk sharing के जरिए deletion force करने की कोशिश भी विफल रही

Time Machine restore के दौरान आई लगातार दिक्कतें

  • पिछले शाम का backup समेत Time Machine backups मौजूद थे, और ज्यादातर महत्वपूर्ण data cloud में होने से complete recovery पर बहुत जोर नहीं था
  • पहले drive erase की गई और macOS Recovery से MacBook Pro के factory-default system Ventura को फिर से install किया गया
  • macOS शुरू होने पर Migration Assistant से network Time Machine backup तक पहुंचा गया, और पर्याप्त storage space बचाने के लिए कुछ restore items को uncheck किया गया
  • restore के दौरान Ventura बीच में रुक गया और बाद में resume नहीं हुआ
  • इसके बाद Mac को उस समय उपयोग में रहे macOS Sonoma में upgrade किया गया
    • upgrade सफल रहा, लेकिन install हुआ version 14.4 था
    • पुराने Mac में 14.3.1 install था
    • startup stage में सीधे restore करने की कोशिश version difference की वजह से allow नहीं हुई

Sonoma 14.4 में network Time Machine mount की समस्या

  • default Sonoma user account बनाकर Migration Assistant चलाया गया
  • Migration Assistant ने Time Machine backup संभालने वाले network Mac को ढूंढ लिया और पहचान भी लिया
  • लेकिन वह बच्चे के backup volume को mount नहीं कर सका, और बार-बार “Mount failed” दिखा
  • forum खोजने पर पता चला कि Sonoma में SMB/Samba-आधारित network mount प्रक्रिया Time Machine restore के लिए टूटी हुई है, और कोई समाधान नहीं मिला
  • यह समस्या macOS 14.4 में भी बनी हुई लगती थी

अंतिम recovery: backup को external SSD पर कॉपी कर manual transfer

  • पूरा Migration Assistant restore छोड़कर केवल जरूरी apps और files को manually recover किया गया
  • network backup संभालने वाले Mac पर उस computer की disk image पर double-click किया गया और Time Machine volume password डाला गया
    • network Time Machine volume पर हमेशा अलग password सेट किया गया था
  • सबसे नया timestamp वाला disk icon ढूंढकर उसे खाली external 1TB SSD पर कॉपी किया गया
  • external SSD को MacBook Pro के temporary account से connect करके जरूरी files transfer की गईं
    • इसमें home directory folders की ज्यादातर contents शामिल थीं
    • बड़े download files और कुछ अनावश्यक video files को छोड़ा गया
  • external SSD को कुछ समय तक संभालकर रखने का फैसला किया गया, ताकि कोई file छूट जाए तो बाद में recover की जा सके

वे विकल्प जिन्हें आजमाया नहीं जा सका

  • network backup के लिए इस्तेमाल हो रही Time Machine drive को backup-managing Mac से unmount करने के बाद बच्चे के Mac से सीधे connect किया जा सकता था
    • इस स्थिति में संभव है कि वह Migration Assistant के source point के रूप में दिखती
  • mounted Time Machine disk image से virtual disk कॉपी करके external 1TB SSD को Mac source volume जैसा दिखाया जा सकता था
    • यह तरीका वास्तव में काम करता या नहीं, इसकी पुष्टि नहीं हुई
    • अगर सफल होता, तो संभव था कि Migration Assistant से सीधे restore हो जाता
  • पहले ही कई घंटों का काम और एक दिन से ज्यादा की कोशिश लग चुकी थी, और उपयोगकर्ता directory-level perfect recovery को लेकर बहुत आग्रहशील नहीं था, इसलिए आगे प्रयोग नहीं किए गए

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

1 टिप्पणियां

 
GN⁺ 2024-04-05
Hacker News टिप्पणियाँ

  • अगर लेखक ने external storage device से Mac को boot किया होता और फिर internal disk से गैर-ज़रूरी फाइलें हटाई होतीं, तो शायद बेहतर रहता: Use an external storage device as a Mac startup disk
    यह बात चौंकाने वाली थी कि Apple Silicon आधारित Mac में external boot के समय सभी ports एक जैसे नहीं होते
    storage device पर macOS install करते समय Mac laptop में बाईं तरफ के ports में सबसे बाएँ USB-C port से बचना चाहिए, और iMac/Mac mini/Mac Studio/Mac Pro में भी मॉडल के हिसाब से ऐसे USB-C ports होते हैं जिनसे बचना चाहिए
    कहा गया है कि install पूरा होने के बाद उसे किसी भी port में जोड़ा जा सकता है

    • व्यावहारिक रूप से यही कोशिश पहले ही की जा चुकी थी
      लेखक ने अलग partition recoveryOS में boot करके main system partition से फाइलें हटाने की कोशिश की, लेकिन rm वही No space left on device error देकर fail हो गया
      इसलिए जैसा दूसरे लोगों ने कहा, echo -n >file से file truncate करने का तरीका शायद काम कर सकता था
    • अगर file system खुद deadlock जैसी स्थिति में फँस गया था, तो कहीं से भी boot करने पर file system driver के ज़रिए फाइलें हटाने का तरीका काम नहीं करेगा
    • recoveryOS या Mac Share Disk/Target Disk mode से भी काम नहीं हुआ, तो यह तरीका क्यों काम करेगा, यह जानने की जिज्ञासा है
    • ऐसे comments, 8 साल बाद उस समय के पुराने Mac की समस्या हल करने के लिए search कर रहे किसी व्यक्ति के लिए सच में बहुत मददगार होंगे
    • क्या किसी को पता है कि Mac laptop में bootable OS बनाते समय पहला USB-C port क्यों नहीं इस्तेमाल करना चाहिए

  • HFS+ disk structure की थोड़ी-बहुत जानकारी के आधार पर अंदाज़ा लगाएँ, तो लगता है journal file भी भर गई थी, और deletion के लिए journal में write करना पड़ता है तथा कभी-कभी उसे बढ़ाना भी पड़ता है, इसलिए delete करना खुद अस्थायी रूप से और space माँगने वाली अजीब स्थिति बन गई होगी
    macOS ने drive में सिर्फ 41KB बचने तक लगातार फाइलें लिखीं
    मैंने गलती से NTFS और FAT32 को 0 bytes तक भर दिया है, लेकिन तब भी कुछ delete करना संभव था
    forums देखने पर लगता है कि Sonoma ने Time Machine restore के लिए SMB/Samba आधारित network mount प्रक्रिया खराब कर दी, और 14.4 में भी इसका कोई समाधान अब तक नहीं दिखता
    अनुभव से कहूँ तो SMB, लगभग 10.12~10.13 के समय से अविश्वसनीय हो गया है और bugs बहुत बढ़ गए हैं; अब तो लगता है Apple को इसकी working की परवाह भी नहीं है
    जिन लोगों के पास Mac का दशकों का अनुभव नहीं है, उनके लिए ऐसी chain reaction जैसी system failures की स्थिति में क्या करना होगा, यह सोचना भी नहीं चाहता
    मेरे पास भी Mac का दशकों का अनुभव नहीं है, लेकिन ऐसी स्थिति में मैं पहले fsck आज़माता; यहाँ उसका ज़िक्र न होना अजीब है
    अगर disk की contents को दूसरी disk पर copy करके format करने और वापस restore करने का विकल्प न हो, तो मैं APFS documentation(https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) देखकर dd और hex editor से यह ढूँढने की कोशिश करता कि free space बनाने के लिए कहाँ क्या ठीक करना होगा

    • यह journaling file system के लिए सही है, लेकिन copy-on-write (CoW) file system में हर बदलाव एक नया file tree बनाकर किया जाता है, और फिर root को उस नए tree की ओर point कराया जाता है
      उसके बाद garbage collection, उन files को ढूँढकर storage में वापस करती है जो अब active tree का हिस्सा नहीं हैं
      आम तौर पर tree changes की मात्रा को manageable रखने के लिए changes को batch में process किया जाता है, और इसी design की वजह से file system snapshots किसी खास tree के लिए एक अतिरिक्त reference बन जाते हैं
      इस प्रक्रिया में space चाहिए, लेकिन CoW file systems आम तौर पर ऐसे कारणों के लिए emergency storage अलग से reserve रखते हैं
    • Apple ने Samba के GPLv3 अपनाने के बाद बहुत पहले ही अपनी implementation पर switch कर लिया था: https://lists.samba.org/archive/samba-announce/2007/000122.html, https://www.engadget.com/2011-03-24-apple-to-drop-samba-networking-tools-from-lion.html
    • Apple की ही तरह SMB performance कुछ साल पहले बहुत खराब लगती थी, और हाल में भी बस किसी तरह ठीक-ठाक है; वही hardware होने पर भी यह NFS से, और विडंबना यह कि Appleshare से भी, कहीं धीमी है
      कुछ साल पहले 10GbE से बड़े NAS से जुड़े Hackintosh पर BlackMagic Disk Speed Test से मापा गया था कि Windows का SMB 900MB/s, macOS का SMB 200MB/s, और macOS का NFS व AFP दोनों 1000MB/s दे रहे थे
      professional work से जुड़े macOS features दुर्भाग्य से हास्यास्पद स्तर के हैं
      लोग कहते हैं AFP मर चुका है, लेकिन मेरे Mac Pro पर यह client के रूप में अभी भी ठीक चलता है, और SMB की तुलना में इसकी performance इतनी बेहतर है कि यह लगभग मज़ाक जैसा लगता है
    • जब खुद पर बीतती है तो मज़ेदार नहीं होता, लेकिन BTRFS और ZFS में भी यही हो सकता है
      अगर आख़िर तक पूरी तरह भर दिया जाए, तो समस्या आ सकती है
      BTRFS, metadata space बाकी रहते read-only mode में जाने की कोशिश करता है ताकि आप safe mode में फिर mount करके कुछ delete कर सकें, लेकिन यह कोई परफ़ेक्ट सुरक्षा नहीं है
      जहाँ तक मुझे पता है, NTFS और FAT32 journaling file systems नहीं हैं
    • अभी तक यही एकमात्र सही technical explanation लग रही है

  • अपनी पहली नौकरी में मेरे साथ ऐसा हुआ था
    गलती से मैंने cluster को junk files से भर दिया था, और system administrator ने इसे जल्दी ठीक करने के लिए ईमेल भेजने शुरू कर दिए, लेकिन rm काम नहीं कर रहा था
    तभी मैंने सीखा कि जब delete काम न करे तब भी file truncate अक्सर काम कर जाता है, इसलिए जब rm foo काम न करे तो कई बार cat /dev/null > foo इस्तेमाल किया जा सकता है

    • shell में :>filepath अक्सर काम करता है
      हालांकि कुछ filesystems में यह भी काम नहीं कर पाता
      ऐसे में बस यही उम्मीद की जा सकती है कि filesystem size बढ़ाने, size घटाने, अस्थायी अतिरिक्त storage, या किसी lower-level subsystem में backing storage जोड़ने/हटाने को support करता हो
      btrfs जैसे मामलों में single block device layout पर वापस जाने के लिए अलग command की ज़रूरत पड़ सकती है
    • कुछ साल पहले ऐसी स्थिति थी जहाँ वह critical infrastructure जिसे filesystem पर हमेशा लिख पाने की क्षमता चाहिए थी, deadlock में फँसकर recovery के बाहर टूट सकता था
      इसलिए backup process को समय-समय पर garbage data सीधे /dev/null में भेजने के लिए सेट किया गया था, और शायद वह गंदा hack आज भी चल रहा होगा
      /dev/null जादू जैसा है, उसके बारे में पढ़ना वाकई फायदेमंद है
    • असल में सिर्फ >file भी काफी है
    • लेकिन जैसा यहाँ कई comments में कहा गया है, truncate भी fail हो सकता है
      21वीं सदी के filesystem formats UFS से कहीं ज़्यादा जटिल हैं, और snapshots तथा journaling जैसी सुविधाओं की वजह से filesystem के अपने ही deadlock में फँसने के नए तरीके पैदा हुए हैं
    • एक बार debugging के लिए Samba log level बहुत ऊँचा सेट कर दिया था और बाद में उसे वापस करना भूल गया, जिससे एक विशाल log file ने ZFS root SSD पूरा भर दिया
      आखिरकार truncate से ही recovery करनी पड़ी
      मुझे पता था कि ZFS ऐसी स्थिति में बेहतर है, लेकिन जब सच में सब बिगड़ गया हो तो जो “आह... धत्” वाली डूबती हुई भावना आती है, वह फिर भी वैसी ही रहती है

  • Time Machine लगता है लगातार खराब होता जा रहा है
    समझ नहीं आता कि इसे stable और सही तरीके से काम करने लायक बनाने की motivation क्यों नहीं है
    sparse bundle के corrupt हो जाने और नया backup शुरू करने की मजबूरी, या feature failure जैसी चीज़ें देखने के बाद, अब मुझे लगता है कि Time Machine सेट up करने की खास value नहीं बची
    यह iOS/iPadOS backups के बिल्कुल उलट है, जो हर बार ठीक से चले

    • क्योंकि वे अब Time Capsule बेचते ही नहीं हैं
      Apple चाहता है कि लोग सब कुछ iCloud में backup करें ताकि services revenue बढ़े
    • Mac न इस्तेमाल करने वाले के नज़रिए से, यह ऐसा विनाशकारी और बिना किसी बहाने वाला bug लगता है, जिस पर अगर यह किसी penguin mascot वाले या Washington में headquartered desktop operating system में होता, तो भयंकर आलोचना होती
    • बहुत बार ऐसा हुआ है कि Time Machine ने अचानक फैसला कर लिया कि अब वह काम नहीं करना चाहता, और backup मिटाकर फिर से शुरू करना पड़ा
    • Scott Forstall को निकालने के बाद से macOS quality control गिरता गया है, और सच कहें तो उसके रहते भी यह कोई हैरतअंगेज़ स्तर पर नहीं था
    • मेरा अनुभव अलग है
      मैं कई Mac पर Samba share के ऊपर Time Machine को कई सालों से चला रहा हूँ, और मुझे तो सिर्फ सुधार ही दिखे हैं
      पहले Time Machine sparse bundle अक्सर corrupt हो जाता था, और उसे दोबारा बनाना पड़ता था या किसी पुराने ZFS snapshot को restore करके आगे बढ़ना पड़ता था
      तब शायद यह SMB नहीं बल्कि AFP था
      हाल के समय में किसी भी device पर यह समस्या नहीं हुई, हालांकि मैंने Time Machine backups के लिए recommended कुछ खास flags smb.conf में enable कर रखे हैं

  • दूसरी ओर ZFS में slop space होता है, ताकि बड़े operations के दौरान space खत्म होने से filesystem रुक न जाए
    default रूप से यह volume space का 3.2% reserve करता है, अधिकतम 128GB तक
    इसलिए अगर आप Linux kernel tuning parameter spa_slop_shift बदलकर slop space घटाते हैं, तो files delete operation को सफलतापूर्वक पूरा करने के लिए bonus space के रूप में अधिकतम 128GB तक वापस पा सकते हैं: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

    • सही बात
      इसी वजह से disk space का एक तय हिस्सा reserve करने की सुविधा ZFS या Linux के आने से दशकों पहले से “असली” filesystems की आम विशेषता रही है
      1980s के ज़्यादातर MS-DOS shareware terminal programs सीमित bandwidth connection पर file download बहुत अच्छी तरह कर लेते थे, जैसे आज का MS Windows उस तरह के मामूली लगने वाले काम में भी बहुत खराब है
    • ext4 में भी यही सुविधा है, बस उसका नाम reserved blocks है
      विवरण के लिए man tune2fs देखें
      ज़्यादातर दूसरे filesystems, चाहे modern हों या कम modern, में भी यही बात लागू होती है
      याद पड़ता है कि 1980s के SunOS के UFS में भी यह था: https://en.wikipedia.org/wiki/SunOS

  • लोगों के लिए यह समझना मुश्किल होता है कि किसी चीज़ को delete करने के लिए वास्तव में अस्थायी या स्थायी रूप से और ज़्यादा space की ज़रूरत पड़ सकती है
    दूसरे comments में विस्तार से बताया गया है कि snapshots, journaling जैसी modern filesystem सुविधाएँ delete के लिए free space से allocation क्यों माँगती हैं
    इसी तरह दूसरे क्षेत्रों में भी, Wikipedia के पहले दशक के दौरान अक्सर समझाना पड़ता था कि pages delete करके server space बचाने की कोशिश का असर वास्तव में उलटा पड़ सकता है
    कम से कम 2004 के आसपास के बाद से delete करने पर internal database में एक record जोड़ा जाता था
    Rahul Dhesi के ZOO archive format में entries delete करना सिर्फ header record में एक flag सेट करना था, और VMS-style file versioning भी था जहाँ नया version जोड़ने पर पुराने version को overwrite नहीं किया जाता था
    MS/DR/PC-DOS और FAT के दौर में, अगर delete recovery utility install हो, तो file delete करते समय recovery information वाले database में नया entry save करने के लिए और space लग सकता था
    कुछ पुराने disk compression utilities metadata को भी compress करते थे, इसलिए metadata change से compression ratio बदलकर externally visible volume size वास्तव में बढ़ जाने जैसी दुर्लभ स्थिति भी बन सकती थी
    delete करके space खाली होता है यह विचार बहुत आम है, लेकिन सख्ती से देखें तो यह हमेशा सही नहीं है

  • अक्टूबर 2018 में मुझे भी यही समस्या हुई थी, और मैंने इसे नीचे दिए गए Stack Overflow सवाल में दर्ज किया था
    किस्मत से एक अतिरिक्त APFS partition था जिसे हटाकर मैं disk space खाली कर सका
    यह पता लगाने में काफी समय लगा, और तब तक मैं सचमुच panic की हालत में था
    https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
    macOS Mojave को अभी-अभी update करने के बाद .dmg बनाते समय मैंने disk पूरी भर दी और system फ्रीज़ हो गया
    reboot करने पर kernel panic हुआ, recovery mode में boot करके disk mount की, फिर terminal में rm /path/to/large/file चलाया, लेकिन No space left on device आया
    यह मूलतः 2008 के Unix thread वाली ही समस्या थी: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
    echo x > /path/to/large/file से भी कुछ नहीं हुआ, और मुझे “drive मिटाकर backup से restore करो” के अलावा कोई और सुझाव चाहिए था

    • लगभग 1GB का एक छोटा अतिरिक्त partition बनाकर रखना अच्छा insurance हो सकता है
      यह कुछ वैसा ही है जैसे पुराने Unix filesystems root के लिए 5% space reserve रखते थे
    • उस StackExchange पोस्ट पर बाद में कुछ और संभावित समाधान भी जोड़े गए
      virtual memory partition हटाने से, अगर वह पर्याप्त बड़ा हो, तो file delete करने लायक space वापस मिल सकती है
    • APFS में यह इतना सीधा नहीं है
      क्योंकि container वास्तव में उपयोग होने पर ही allocate होते हैं

  • यह प्रभावशाली है
    मैंने ऐसी स्थिति नहीं देखी जहाँ rm भी fail हो जाए, लेकिन 256GB या उससे कम internal storage वाले आधुनिक Mac का इस्तेमाल और प्रबंधन करने की झुंझलाहट जरूर झेली है
    इसलिए मैं लगभग 16GB की एक placeholder file बनाकर रखता हूँ
    जब भी space भर जाने से update या कोई और काम रुक जाए, तो ncdu से सर्जिकल सफाई करने के बजाय बस वही file delete कर देता हूँ

    • मैंने CockroachDB को भी node start होते समय यही करते देखा है: https://www.cockroachlabs.com/docs/v23.2/cluster-setup-troubleshooting#automatic-ballast-files
    • placeholder file का बड़ा फायदा यह है कि जरूरत पड़ने पर आप वह space खाली करके long-term solution लागू करने के लिए समय खरीद लेते हैं
      जैसे किसी कर्मचारी या उपकरण के एक घंटे की लागत में पहले से चार गुना बड़ी नई drive खरीद लेना

  • iPhone पर भी मेरे साथ कुछ ऐसा ही हुआ था
    disk इतनी भर गई थी कि कुछ delete करने पर भी व्यवहार में लगता था जैसे कुछ हुआ ही नहीं
    reboot करने पर मैं login नहीं कर सका, फिर दोबारा reboot किया तो boot loop में फँस गया
    एक और reboot के बाद यह ऐसी असंगत स्थिति में boot हुआ जहाँ home screen पर app icons तो थे, लेकिन असली apps गायब थे, icons खाली थे और वे खुल भी नहीं रहे थे
    data integrity की चिंता में मैंने आखिरकार backup से restore किया
    मुझे पूरा यकीन है कि यह APFS के copy-on-write behavior और snapshot support की वजह से हुआ
    अगर बदलाव तुरंत स्थायी रूप से लागू नहीं होते और file के पुराने versions snapshots में बने रहते हैं, तो snapshot metadata के लिए भी जगह न बचे तो समस्या खड़ी हो जाती है
    हो सकता है disk space कम होने पर snapshots छोड़ दिए जाएँ, लेकिन तब भी CoW metadata की समस्या बनी रहती है

    • मेरे साथ भी बिल्कुल यही हुआ था
      हैरानी की बात है कि 2024 में भी, जबकि APFS में इतने स्मार्ट volume management features हैं, केवल user storage भर देने से iPhone जैसे “sealed” device को ऐसी हालत में पहुँचा देना संभव है जहाँ DFU recovery की जरूरत पड़ जाए
      इसके उलट, जब मैंने गलती से single data/boot volume वाले अपने Windows 11 work laptop की space पूरी भर दी थी, तब भी वह boot हो गया और मैं समस्या साफ कर सका

  • कुछ समय पहले Linux installation के system partition पर भी मेरे साथ ऐसी ही स्थिति हुई थी
    शुरू से ही partition बहुत छोटा था, और updates जमा होते-होते इतनी तंगी हो गई कि कुछ delete करना शुरू करने भर की भी जगह लगभग नहीं बची
    कोई ऐसा subdirectory ढूँढने में लगभग 30 मिनट लग गए जिसमें थोड़ा-सा भी कुछ delete किया जा सके
    यह वैसा लगा जैसे ऐसे कमरे में फँस गए हों जो इतने सामान से भरा हो कि अंदर की ओर खुलने वाला दरवाज़ा ही न खुल सके
    उस छोटे-से शुरुआती बिंदु से मैं धीरे-धीरे और बड़ी जगह खाली कर सका, और आखिरकार सफाई के बाद partition का आकार बढ़ा दिया ताकि फिर ऐसा न हो

    • मैं जानना चाहूँगा कि शुरुआत में partition बढ़ाया क्यों नहीं गया
      अनुभवी users के लिए सबक शायद यह होना चाहिए कि partition के बाद हमेशा थोड़ी खाली जगह छोड़ी जाए