قد تكون أدوات استخدام القرص مضللة على أجهزة NAS، لأن الدليل قد يكون إما مساحة تخزين محلية عادية أو موضع تثبيت نظام ملفات آخر. بدأ هذا الموضوع في يناير 2026 بمحرك ZimaOS سعته 1 تيرابايت ويظهر استخدام نحو 915 غيغابايت، رغم اعتقاد المستخدم أن لديه نحو 450 غيغابايت فقط من الوسائط. كان الافتراض الأول هو ذاكرة Docker المؤقتة. لكن ناتج الأمر أشار بدلًا من ذلك إلى /DATA/.media، حيث كانت نقاط تثبيت النسخ الاحتياطي والتخزين البعيد متضمنة.
قِس قبل تقليص بيانات Docker
اقترح الرد الأول من المجتمع فحص أكبر المجلدات ضمن /DATA والتحقق من حسابات Docker الخاصة به. كان ذلك منطقيًا، لكن نتيجة المستخدم أظهرت نحو 2.1 غيغابايت فقط ضمن شجرة Docker ونحو 2 غيغابايت من AppData.
لذلك لم يتمكن Docker من تفسير مئات الغيغابايت المفقودة.
/DATA كان القسم شبه ممتلئ.عثر المستخدم الأول على 424 غيغابايت ضمن /DATA/.media/UNTITLED 2
أظهر فحص الحجم نحو 419 غيغابايت من الوسائط العادية، بالإضافة إلى 424 غيغابايت أخرى ضمن /DATA/.media/UNTITLED 2. تعرّف المستخدم على ذلك الاسم باعتباره اسم SSD المستخدم سابقًا كوجهة للنسخ الاحتياطي في ZimaOS.
كان الجزء المربك هو أن محرك النسخ الاحتياطي الفعلي لم يعد متصلًا.
قد تتحول نقطة التثبيت إلى مجلد محلي عادي
نقاط التثبيت في Linux هي أدلة. عند تثبيت محرك USB أو مشاركة SMB، تصل عمليات الوصول إلى الدليل إلى نظام الملفات الخارجي. وإذا اختفى نظام الملفات الخارجي واستمر أحد التطبيقات في الكتابة إلى الدليل نفسه، فقد تُكتب تلك البيانات على نظام الملفات المحلي الموجود تحته.
وهذا يسبب حالة الفشل الكلاسيكية: «هدف النسخ الاحتياطي خارجي، فلماذا امتلأ قرص النظام؟»
لا تحذف دليل .media قبل أن تعرف ما إذا كان مثبتًا
اقترح استكشاف الأخطاء وإصلاحها في المصدر أوامر إزالة مدمّرة بعد التحقق من حالة التثبيت. وهذا الترتيب مهم. فقد يؤدي حذف الملفات من هدف نسخ احتياطي مثبت ونشط إلى محو النسخة الاحتياطية الخارجية الفعلية بدلًا من استعادة البيانات المحلية المخفية.
لأن أمر الحذف كان إرشادًا من المجتمع وليس تعليمات دعم من IceWhale، فلا تعرض هذه الصفحة الأمر باعتباره وصفة عامة للتنظيف.
مستخدم ثانٍ يعيد النمط نفسه بعد انقطاع التيار
لاحقًا في الموضوع، فقد مستخدم آخر لديه قسم صغير للنظام/البيانات على ZimaOS-HD كل المساحة الحرة المتبقية بعد أن تسبب انقطاع التيار في مقاطعة نشاط النسخ الاحتياطي. أما بياناته الخام du بدا الناتج ضخمًا لأنه احتسب أيضًا بيانات RAID المثبّتة وبيانات SMB الموجودة أسفلها /DATA/.media.
استخدم فحصًا على مستوى نظام الملفات نفسه لفصل البيانات المحلية عن نقاط التحميل
أوصى المجتمع باستخدام du فحص يظل على نظام الملفات نفسه بحيث تُستبعد المشاركات الشبكية المحمّلة. في الحالة الثانية، كشف ذلك عن نحو 30 غيغابايت من البيانات المحلية الفعلية أسفل دليل مسمّى بعنوان IP داخل /DATA/.media.
استعاد المستخدم الثاني 30 غيغابايت
بعد التأكد من أن الدليل المسمى بعنوان IP لم يكن نقطة تحميل SMB نشطة، وتحديده على أنه بيانات محلية متروكة أسفل نقطة التحميل، أزال المستخدم المحتويات غير المرغوب فيها وأبلغ عن استعادة 30 غيغابايت.
هذه هي النتيجة الأقوى التي تم التحقق منها في الموضوع.
كانت نظرية المجتمع أن النسخ الاحتياطي كان يكتب بينما كانت الوجهة غير محمّلة
اعتقد المجيب أن عملية النسخ الاحتياطي واصلت الكتابة إلى مسار SMB المتوقع عندما لم تكن المشاركة محمّلة بشكل صحيح، ما أدى إلى كتابة Linux داخل الدليل المحلي بدلًا من ذلك.
يؤكد استرداد 30 غيغابايت وجود ملفات محلية أسفل نقطة التحميل، لكن تفسير تعارض النسخ الاحتياطي الدقيق كان تشخيصًا من المجتمع، وليس منشورًا هندسيًا من IceWhale في هذا الموضوع.
تغيّرت آلية التعامل مع النسخ الاحتياطي والتخزين في ZimaOS حاليًا
توثّق ZimaOS حاليًا مهام النسخ الاحتياطي المُدارة وإدارة التخزين الأوسع نطاقًا. استخدم سير عمل النسخ الاحتياطي الحالي في ZimaOS للمهام الجديدة، وتحقّق من أن الوجهة المقصودة محمّلة فعليًا قبل بدء عمليات الكتابة الكبيرة.
سير عمل أكثر أمانًا للعثور على المساحة المفقودة
- استخدم
dfللتأكد من نظام الملفات المحلي الممتلئ. - افحص نظام الملفات ذلك فقط حتى لا تؤدي نقاط تحميل SMB وUSB وRAID إلى تضخيم الإجماليات.
- تحقّق من Docker وAppData بشكل منفصل.
- افحص
/DATA/.mediaلدلائل نقاط التحميل التي تحتوي على ملفات محلية فعلية. - تأكّد من أن الوجهة غير محمّلة قبل حذف أي شيء أسفل نقطة تحميل.
- بعد التنظيف، تحقّق من المساحة الفارغة واختبر وجهة النسخ الاحتياطي مرة أخرى.
كانت حالة المستخدم الأول المتعلقة بـ424 غيغابايت أكثر التباسًا من حالة المستخدم اللاحق المتعلقة بـ30 غيغابايت
رأى صاحب المنشور الأصلي نحو 424 غيغابايت ضمن دليل يحمل اسم وحدة تخزين SSD للنسخ الاحتياطي غير المتصلة، واعتقد أن هذه البيانات مكررة. ثم انتقل النقاش إلى فحوصات نقاط التحميل واقتراحات التنظيف، لكن أوضح استرداد تم التحقق منه في الموضوع جاء من المستخدم اللاحق الذي استعاد 30 غيغابايت.
هذا التمييز مهم لأن دليلًا موجودًا أسفل /DATA/.media قد يمثل نقطة تثبيت نشطة، أو نقطة تثبيت قديمة، أو ملفات محلية فعلية. ولا يعني تشابه المسار أن إجراء التنظيف الآمن نفسه ينطبق على كل نظام.
استخدم df وdu لطرح سؤالين مختلفين
df يجيب عن سؤال «ما نظام الملفات الممتلئ فعليًا؟» بينما du يجيب عن سؤال «ما الأدلة الظاهرة التي تحتوي على ملفات؟». على جهاز NAS يحتوي على نقاط تثبيت متداخلة، قد تبدو الأداتان متعارضتين لأن du قد ينتقل بشكل递归ي إلى أنظمة ملفات أخرى ما لم يُطلب منه عدم ذلك.
أصبح النقاش أوضح بكثير فقط بعد أن فصل استكشاف الأخطاء بين نظام ملفات ZimaOS-HD المحلي ومحتوى SMB وRAID المثبت.
فقدان الطاقة غير المتوقع يجعل أخطاء نقاط التثبيت أكثر خطورة
بدأت حالة الـ30 غيغابايت اللاحقة بعد انقطاع التيار أثناء إجراء النسخ الاحتياطية. إذا لم تُعَدْ تثبيت وجهة بعيدة بشكل سليم بعد الإقلاع، لكن استؤنفت مهمة النسخ الاحتياطي أو أُعيد تشغيلها، فقد يظل المسار موجودًا كدليل محلي عادي.
بالنسبة إلى مهام النسخ الاحتياطي المهمة، تحقّق من أن الوجهة مثبتة وقابلة للكتابة بعد إعادة التشغيل أو انقطاع الطاقة، قبل افتراض أن المسار القديم لا يزال يشير إلى الوجهة الخارجية.
لا تحذف overlay2 الخاص بـ Docker يدويًا لاستعادة المساحة
في وقت مبكر من النقاش، بدت مسارات overlay الخاصة بـ Docker بارزة بصريًا في مخرجات نظام الملفات. وحذّر المجتمع تحديدًا من حذف ملفات عشوائية من overlay2. ينبغي إدارة طبقة تخزين Docker من خلال Docker أو دورة حياة التطبيق، وليس بحذف أدلة الطبقات عشوائيًا.
يعرض ZimaOS الحالي أيضًا استخدام تخزين التطبيقات
تعرض إعدادات تطبيقات ZimaOS الحالية استهلاك تخزين التطبيقات، وتوفّر تنظيف ذاكرة التخزين المؤقت للتطبيقات المدعومة. وهذا مفيد للتمييز بين نمو التطبيقات الطبيعي والبيانات الموجودة في نقاط التثبيت قبل الانتقال إلى الطرفية.
يوفّر شرح أماكن تخزين تطبيقات ZimaOS الحالية للبيانات وذاكرة التخزين المؤقت خريطة أولية أكثر أمانًا لنظام الملفات.
الأسئلة الشائعة حول المساحة المفقودة
هل كان overlay2 الخاص بـ Docker مسؤولًا عن مئات الغيغابايتات المفقودة لدى المستخدم الأول؟
لا. لم يكن Docker مسؤولًا إلا عن جزء صغير من المساحة المستخدمة في المخرجات المنشورة.
لماذا يمكن للأداة du الإبلاغ عن تيرابايتات على قرص محلي أصغر بكثير؟
يمكنه عدّ أنظمة الملفات البعيدة أو أنظمة RAID المثبتة بشكل递归ي، ما لم يُقيَّد الفحص بنظام الملفات المحلي.
هل تم تأكيد استعادة أي بيانات؟
نعم. استعاد المستخدم اللاحق 30 غيغابايت من بيانات محلية مخزنة أسفل دليل نقطة تثبيت SMB.
