حلّ المجتمع

امتلاء قرص النظام في ZimaOS وتعطّل ترحيل البيانات: المساحة الخالية وبيانات التطبيقات والملفات الصغيرة والاسترداد الآمن

A February-November 2025 thread where a ZimaCube system SSD reached 0 B free after Resilio indexing large data. App-data migration appeared stuck at 5%, then slowly reached 49% and eventually completed after more than a day. The user later said stopping Resilio/indexing prevented the system disk from filling again.

يوضح هذا المصدر سبب إمكانية أن يجعل امتلاء قرص النظام بالكامل في ZimaOS عملية الترحيل تبدو متوقفة من دون أن يؤدي ذلك بالضرورة إلى تدمير RAID الأساسي أو بيانات المستخدم. فقد امتلأ قرص SSD للنظام بسعة 228 جيجابايت في ZimaCube ووصلت المساحة المتاحة إلى 0 بايت بعد أن نمت بيانات الفهرسة والتطبيقات المرتبطة بـ Resilio على قرص نظام التشغيل. ظل الوصول عبر SMB وFinder يعمل، لكن لوحة التحكم أصبحت غير مستقرة، وبقيت عملية الترحيل في البداية عند 5٪.

تحركت عملية الترحيل في النهاية إلى الأمام—45٪، ثم 49٪، ثم اكتملت أخيرًا بعد أكثر من يوم. وذكر صاحب المنشور الأصلي لاحقًا أنه أوقف أيضًا Resilio عن مواصلة الفهرسة والكتابة على قرص النظام. وتوصي وثائق ZimaOS الحالية صراحةً بإبقاء AppData خارج قرص النظام.

كان قرص SSD للنظام ممتلئًا بالكامل

قرص SSD لنظام ZimaOS يعرض استخدام 228 جيجابايت وتوفر 0 بايت بينما ظلت مصفوفة بيانات NAS سليمة
لم تعد هناك مساحة تشغيلية متاحة على قرص النظام المصدر، رغم أن مصفوفة التخزين الكبيرة كانت لا تزال تحتوي على سعة خالية.

بدت عملية ترحيل بيانات التطبيقات عالقة أولًا عند 5٪

شاشة ترحيل ZimaOS تنقل بيانات التطبيقات من ZimaOS-HD إلى Cube بينما عالقة عند 5 بالمئة
عرضت عملية الترحيل نسبة 5٪ لساعات، بينما لم تكن هناك مساحة احتياطية فعلية تقريبًا على قرص النظام.

لم تكن الوتيرة البطيئة تعني أن عملية الترحيل توقفت نهائيًا

رأى المستخدم لاحقًا أن الترحيل انتقل إلى 45٪ ثم إلى 49٪ خلال الليل. وبعد أشهر أكد أنه اكتمل في النهاية، على الأرجح بعد أكثر من يوم.

ترحيل صور تطبيقات ZimaOS من ZimaOS-HD إلى Cube عند 49 بالمئة بعد تشغيله طوال الليل
يمكن أن يستغرق نقل بيانات التطبيقات الكبيرة التي تحتوي على عدد كبير من الملفات الصغيرة وقتًا طويلًا جدًا، حتى عندما يواصل شريط التقدم التحرك.

تحذر إرشادات IceWhale الحالية صراحةً من ملء قرص النظام ببيانات AppData

توضح إرشادات مسارات تخزين التطبيقات الحالية أن قواعد بيانات التطبيقات والصور المصغرة والبيانات الوصفية وغيرها من بيانات AppData قد تملأ قرص النظام الصغير، وتتسبب في عمل التحديثات والتطبيقات والجهاز نفسه بصورة غير طبيعية.

استخدم إرشادات تخزين AppData الحالية.

أوقف التطبيق الذي لا يزال يملأ القرص

لن يكون تحرير بضعة جيجابايت مفيدًا إذا أعاد Resilio أو نموذج LLM أو ذاكرة التخزين المؤقت في Immich أو حاوية أخرى كتابتها فورًا. حدّد التطبيق الذي يستهلك مساحة تخزين النظام وأوقفه قبل إعادة محاولة الترحيل.

وفّر مساحة تشغيلية قبل إعادة محاولة الترحيل

تحتاج عملية الترحيل إلى مساحة لقواعد البيانات والحالة المؤقتة والسجلات وعمليات التطبيقات. احذف أو انقل فقط البيانات التي حددتها بشكل مؤكد؛ ولا تنفذ عمليات تنظيف شاملة على مستوى الجذر داخل أدلة النظام غير المعروفة.

استخدم أداة ترحيل البيانات الحالية بعد استقرار النظام

يمكن لـ ZimaOS الحالي نقل صور Docker وبيانات تطبيقات Docker وقواعد بيانات المستخدم المُدارة بين مساحات التخزين عبر الإعدادات > ترحيل البيانات.

راجع سير عمل ترحيل البيانات الحالي.

قد تكون الأعداد الهائلة من الملفات الصغيرة أبطأ مما يوحي به حجمها الإجمالي

قد تتطلب قواعد بيانات الفهرسة ومجلدات الصور المصغرة والبيانات الوصفية عددًا من عمليات نظام الملفات لكل جيجابايت أكبر بكثير من ملفات الوسائط الكبيرة.

لا تنقل بيانات AppData النشطة يدويًا أثناء الترحيل

نقل أحد المشاركين لاحقًا مجلد AppData الخاص بتطبيق LLM يدويًا بينما كانت عملية الترحيل عالقة بالفعل. وقد يؤدي ذلك إلى عدم تطابق المسار المُعد للتطبيق مع حالة الترحيل في ZimaOS وموقع نظام الملفات الفعلي.

أفاد المصدر أيضًا بوجود مشكلة منفصلة في أسماء ملفات Resilio

بعد أشهر، قال timothy إن Resilio أعاد تسمية ملفات تحتوي على محارف غير مدعومة، ما جعلها تبدو مفقودة في ZimaOS. وصحح صراحةً شكّه السابق في أن ZimaOS قد فقد تلك الملفات.

لا يعني تعطل لوحة التحكم فقدان مجموعة التخزين

كان المصدر لا يزال قادرًا على استخدام SMB وFinder بينما كانت لوحة التحكم تسجل الخروج وتتصرف واجهة الترحيل بصورة غريبة. وهذا تمييز مهم: فقد يؤدي امتلاء قرص النظام إلى تعطيل خدمات طبقة التحكم، بينما تظل مصفوفة البيانات المنفصلة موصولة ومتاحة للقراءة.

حافظ على هذه الأدلة قبل اتخاذ أي إجراءات مدمرة تتعلق بـ RAID أو إعادة التثبيت.

افحص قرص النظام قبل بدء عملية ترحيل أخرى

تحقق من الأدلة التي تستهلك مساحة قرص النظام، وحدد التطبيق المسؤول عنها، وأوقف الجهة التي تكتب البيانات. وإذا كان من الآمن إزالة التطبيق وإعادة إنشائه، فأزل بيانات ذاكرة التخزين المؤقت أو صور التطبيقات القابلة لإعادة الإنشاء عبر عناصر التحكم المدعومة، بدلًا من حذف أدلة عشوائية.

بعد توفير مساحة تشغيلية، أعد تشغيل الخدمة أو التطبيق المتأثر فقط عند الحاجة، وتحقق من بقاء المساحة الخالية مستقرة قبل الترحيل.

عملية الترحيل الحالية عملية محكومة بملء الشاشة

تذكر وثائق IceWhale الحالية أن العمليات الأخرى تصبح غير متاحة أثناء تشغيل ترحيل البيانات. خطط لفترة توقف للتطبيقات التي يجري نقل بياناتها، وتجنب عمليات النقل اليدوية المتزامنة، ودع الترحيل يصل إلى حالة واضحة للاكتمال أو الخطأ قبل تعديل المجلدات نفسها.

إعادة التثبيت هي الحل الأخير، وليست الاستجابة الأولى لامتلاء المساحة إلى 0 بايت

إذا كانت بيانات المستخدم والتخزين سليمة، فقد يؤدي تحرير مساحة النظام وإكمال ترحيل AppData إلى استعادة النظام من دون إعادة بناء NAS. وإذا أصبحت إعادة التثبيت ضرورية، فانسخ بيانات التطبيقات والبيانات الوصفية للتخزين والملفات المهمة احتياطيًا أولًا، واتبع إرشادات الاسترداد وإعادة التثبيت الحالية.

الأسئلة الشائعة حول امتلاء قرص النظام

هل اكتملت عملية الترحيل في المصدر في النهاية؟

نعم. ذكر صاحب المنشور الأصلي لاحقًا أنها اكتملت بعد أكثر من يوم.

هل يثبت بقاء شريط تقدم الترحيل عند 5٪ فقدان البيانات؟

لا. فقد تحرك لاحقًا في المصدر، بينما ظل SMB وRAID قابلين للوصول.

ما أول إجراء ينبغي للمستخدمين الحاليين اتخاذه عندما يمتلئ ZimaOS-HD؟

أوقف التطبيق الذي لا يزال يكتب البيانات، ووفّر مساحة خالية بأمان، ثم استخدم عناصر التحكم الحالية الخاصة بترحيل البيانات وAppData بدلًا من حذف ملفات نظام غير معروفة.