“Built-in storage almost full” is a symptom, not a single ZimaOS bug. This source thread exposed at least three different causes: a Backup task whose USB destination disappeared and was effectively recreated under local /DATA، وسجل JSON منفلت لـDocker نما إلى 519 غيغابايت، ونظام مختلف كان فيه «اقتراب امتلاء التخزين المدمج» عرضًا لا مشكلة واحدة في ZimaOS. كشف هذا الموضوع المصدر عن ثلاثة أسباب مختلفة على الأقل: مهمة نسخ احتياطي اختفت وجهتها على USB وأُعيد إنشاؤها فعليًا ضمن التخزين المحلي /DATA/.media استهلك 409 غيغابايت.
الاستجابة الأكثر أمانًا هي القياس أولًا، وتحديد الخدمة المالكة، وإيقاف عملية الكتابة، ثم تنظيف البيانات المؤكدة فقط. لا تحذف /DATA/.docker أو .media أو AppData بشكل متكرر لمجرد أنها كبيرة.
/DATA حتى مع توفر عدة تيرابايت في مجموعة البيانات الكبيرة.لا يضمن ترحيل بيانات التطبيقات أن كل كتابة مستقبلية ستغادر /DATA
استخدم فحوصات du للقراءة فقط للعثور على أكبر دليل
شارك المستخدم المصدر ما يلي:
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrلا يعدّل هذا الملفات. كرّر الأمر على دليل مثير للريبة لتضييق نطاق أكبر مجلد فرعي.
كان وجهة النسخ الاحتياطي المفصولة أول سبب مؤكد
اكتشف Cobblerkid أن مهمة النسخ الاحتياطي كانت تتوقع وحدة USB خارجية. وبعد فصل الوحدة، أُعيد إنشاء بنية النسخ الاحتياطي ضمن /DATA وظلت المهمة المجدولة تكتب حتى امتلأت وحدة التخزين المحلية.
وافق Zima-Jerry على أن هذا يبدو مشكلة وأحالها داخليًا. وهذا يجعل الأمر يتجاوز كونه مجرد نظرية من المجتمع.
وجد مستخدم آخر سجل JSON لحاوية بحجم 519 غيغابايت
فحص مشارك ثانٍ دليل حاوية Docker واحدة ووجد *-json.log ملف بحجم يقارب 519 غيغابايت، ونُسب إلى حاوية Home Assistant.
أزال المستخدم الحاوية واستعاد المساحة. لا تعمم ذلك إلى «احذف سجلات Docker يدويًا»؛ حدّد أولًا الحاوية التي تُصدر السجلات بكثرة، وافحص سجلاتها، وأصلح الخطأ المتكرر الذي ينشئ السجل.
كان لدى نظام ثالث 409 غيغابايت ضمن /DATA/.media
نشر مستخدم آخر تفصيلاً للحجم، حيث بلغت بيانات التطبيقات العادية نحو 225 غيغابايت، .docker 3.5 غيغابايت فقط، لكن .media استهلك 409 غيغابايت. وهذا يوضح سبب عدم قدرة أمر تنظيف واحد على حل كل بلاغات «امتلاء القرص».
يكشف الإصدار الحالي من ZimaOS عن مزيد من عناصر التحكم في تخزين التطبيقات وذاكرة التخزين المؤقت
توضح وثائق IceWhale الحالية أن الإعدادات ← التطبيقات تعرض موقع App data وتتيح تنظيف الاستخدام/ذاكرة التخزين المؤقت لكل تطبيق. يؤدي إبقاء AppData على مصفوفة التخزين الرئيسية إلى تقليل الضغط على محرك النظام الصغير.
استخدم عناصر التحكم الحالية في تخزين تطبيقات ZimaOS قبل محاولة التنظيف باستخدام الصَدَفة.
ترتيب استرداد أكثر أمانًا
- أوقف المهمة/التطبيق الذي لا يزال ينشئ البيانات؛
- قِس
/DATAللقراءة فقط؛ - حدّد الملف/المجلد والمالك بدقة؛
- انسخ احتياطيًا بيانات AppData/الإعدادات المهمة؛
- استخدم عناصر التحكم المدعومة للتطبيق/ذاكرة التخزين المؤقت حيثما أمكن؛
- تأكد من بقاء المساحة الحرة مستقرة بعد إعادة التشغيل.
- احذف فقط البيانات التي يمكن التخلص منها أو التي ثبت خطؤها؛
docker image prune لا يحل كل مشكلات مساحة Docker
في المصدر، ذكر raller1028 أن docker image prune -a كطريقة لإزالة الصور التي لا تستخدمها الحاويات. يمكن أن يستعيد ذلك طبقات الصور غير المستخدمة، لكنه لن يحل مشكلة سجل JSON نشط بحجم 519 غيغابايت، أو وجهة Backup منفلتة، أو بيانات المستخدم ضمن .media.
استخدم فحص الحجم لتحديد الفئة أولًا. قد يحرر أمر تنظيف موجّه إلى الفئة الخطأ مساحة ضئيلة جدًا، مع إنشاء مخاطر جديدة.
سجل JSON ضخم يعني أن حلقة أخطاء الحاوية ما زالت مهمة
أدى حذف الحاوية المسببة للمشكلة إلى توفير مساحة لأحد المستخدمين، لكن السؤال الأفضل على المدى الطويل هو سبب كتابة التطبيق مئات الغيغابايت من السجلات. افحص السجلات الحديثة بحثًا عن أخطاء متكررة أو حلقات إعادة تشغيل أو أجهزة غير متاحة أو مشكلات في الإعداد قبل إعادة تثبيت عبء العمل نفسه.
إذا بدأت الحاوية المُعاد إنشاؤها في إنشاء السجلات مجددًا فورًا، فستعود حالة امتلاء القرص.
تعامل مع .media كتخزين مُدار، وليس كذاكرة تخزين مؤقتة يمكن التخلص منها
الـ409 غيغابايت /DATA/.media قد يحتوي المثال على بيانات تحميل/ملفات مُدارة فعلية بدلًا من ذاكرة تخزين مؤقتة مؤقتة. قبل حذف أي شيء هناك، حدّد أي وحدة تخزين/مشاركة/تطبيق يملكها وتأكد من وجود الملفات نفسها في مكان آخر.
الأسئلة الشائعة حول امتلاء التخزين المدمج
هل أثبت المصدر أن ترحيل AppData نفسه فشل؟
لا. كان صاحب المنشور الأصلي قد نقل الفئات المُدارة؛ وكان الامتلاء المؤكد ناتجًا عن هدف Backup غير المتصل.
هل من الآمن حذف دليل .docker بالكامل؟
لا. فقد يحتوي على حالة الحاويات النشطة والسجلات والصور وتبعيات التطبيقات.
ما أفضل أمر أول من المصدر؟
للقراءة فقط du فحص حجم باستخدام /DATA للتعرّف على الشجرة الفرعية الكبيرة الفعلية.
