تغيّرت الإجابة المختصرة بعد اختبار المجتمع لـ ZimaOS
تعاملت الردود الأولى مع ZimaOS باعتباره نظامًا بسيطًا على نمط الأجهزة الجاهزة، من دون مدير حزم تقليدي. ونصحت بعدم افتراض توفر apt install أو إمكانية إجراء تعديلات دائمة على نظام التشغيل الأساسي. واقتُرحت حاويات Docker وآلة افتراضية تعمل بنظام Debian أو Ubuntu كحدود عزل أنظف.
أضافت الاختبارات العملية اللاحقة تصحيحًا مهمًا: عثر أحد المشاركين على /usr/bin/mergerfs وmergerfs-fusermount مثبتين مسبقًا على جهاز ZimaCube، بينما لم يُعثر على أي ملف ثنائي لـ SnapRAID. وحدد مشارك آخر أن إصدار mergerfs المرفق كان قديمًا أثناء تصحيح مشكلة التنافس عند الإقلاع. وكانت النتيجة ليست أن «التثبيت الأصلي مستحيل»، بل أن «تعديلات المضيف اليدوية غير مدعومة وحساسة للإصدار».
عملت الملفات الثنائية اليدوية، لكنها حملت مخاطر التحديث
بنى أحد المستخدمين ملفات تنفيذية في WSL2، ثم نسخها إلى ZimaOS، وأفاد بنجاح إعداد يتكون من قرصين للبيانات وقرص واحد للتكافؤ. وأشار مسؤول صيانة mergerfs إلى أن الإصدارات الساكنة يمكن أن تبسّط النشر اليدوي، لكن سلوك الحاويات يعتمد على ما إذا كانت بيئة التشغيل تتمتع بصلاحيات جذر كافية لإتاحة تركيب FUSE كما هو مطلوب.
حذّرت ردود المجتمع مرارًا من أن نسخ الملفات الثنائية إلى نظام شبيه بالأنظمة غير القابلة للتغيير ينشئ أعمال صيانة إضافية. فقد تستبدل تحديثات OTA التغييرات اليدوية أو تتعارض معها، كما احتوت تعليمات Linux المُنشأة بالذكاء الاصطناعي على أخطاء أثناء تجارب المستخدم.
أنشأ المجتمع طبقة systemd-sysext
نشر أحد المساهمين لاحقًا مشروع systemd-sysext مجتمعيًا لـ ZimaOS. وكان هدفه إضافة mergerfs وSnapRAID كطبقة امتداد منفصلة بدل تعديل النظام الأساسي للقراءة فقط مباشرة.
أكد اختبار مضبوط على ZimaCube Pro أن الطبقة تم تحميلها، وأتاحت mergerfs 2.42.0 وSnapRAID 14.5، وتمكنت من تركيب مجموعة mergerfs مؤقتة. أنشأ المختبر ملفًا عبر المسار المجمّع، وتحقق من ظهوره على الفرع الأساسي، ثم أجرى إلغاء التركيب بصورة سليمة.
لم يتضمن ذلك الاختبار تمرينًا كاملًا على تكافؤ SnapRAID والاسترداد. كما عطّل المختبر المؤقتات والخدمات الافتراضية قبل ضبط أي شيء، حتى لا تتعامل بالخطأ مع أقراص حقيقية.
اكتُشفت حالتا تنافس عند الإقلاع وصُححتا
بعد إعادة التشغيل، وجد أحد المستخدمين أن المجموعة كانت تفشل أحيانًا، بينما ينجح تشغيلها يدويًا لاحقًا. وحدد صاحب الامتداد حالتي تنافس منفصلتين. أولًا، كان الحارس الأصلي يعثر على ملف mergerfs الثنائي القديم الذي يوفّره نظام التشغيل الأساسي، فيبدأ المجموعة قبل دمج الملف الثنائي الأحدث الخاص بالامتداد. وفحص الحارس المعدّل SnapRAID، الذي لا يوفّره إلا الامتداد.
ثانيًا، كان mergerfs قد يعيد نتيجة نجاح قبل تركيب أقراص الفروع الفعلية، ما ينتج مجموعة فارغة تخفي وحدات التخزين التي تصل لاحقًا. ولم تكن حلقة بسيطة تعتمد على Restart=on-failure قادرة على اكتشاف هذه الحالة التي تنجح ظاهريًا لكنها فارغة. وأضاف المشروع فحوصًا صريحة تنتظر تركيب كل فرع، وترفض إنشاء المجموعة فوق فرع مفقود.
أفاد صاحب المشروع بإجراء تحقق بعد إعادة تشغيل باردة على ZimaOS 1.6.1 عقب هذه التغييرات. كما أفاد مستخدم لديه حاوية TerraMaster ذات أربعة أقراص بأن المجموعة ظهرت في النهاية بعد أن استغرق تركيب الأقراص نحو دقيقة تقريبًا.
تظل سلامة SnapRAID بحاجة إلى مراجعة المشغّل
تضمن الامتداد حدًا لحذف الملفات، يهدف إلى إيقاف المزامنة بعد اكتشاف عدد كبير بشكل غير متوقع من عمليات الحذف. وتساءل مستخدم لاحق عن كيفية تجاوز هذا الحد بعد حذف آلاف الملفات عمدًا. ولم يحسم النقاش هذه المسألة التشغيلية.
يجب على أي شخص يقيّم المشروع مراجعة مسارات الفروع، ومسارات التكافؤ، والمؤقتات، وحدود الحذف، وموقع بيانات التطبيقات قبل تفعيل المهام الآلية. ولا يُثبت نجاح فحص الملف الثنائي أو تركيب mergerfs أن استرداد التكافؤ قد اختُبر على مجموعة بيانات إنتاجية.
حدود الدعم
هذا تكامل متقدم من إنشاء المجتمع، وليس ميزة تخزين في ZimaOS مدعومة من IceWhale. وتختلف Docker وآلة Linux الافتراضية الكاملة والملفات الثنائية الساكنة وsysext في الصلاحيات وخصائص الاستمرارية. وأقوى نتيجة توصل إليها النقاش هي أسلوب الامتداد الذي خضع للاختبار، لكن ينبغي مع ذلك تقييمه على وحدات تخزين مؤقتة قبل إدخال أي بيانات حية.
الأسئلة الشائعة
هل mergerfs مضمّن بالفعل في ZimaOS؟
تحقق أحد المشاركين من وجود ملف ثنائي لـ mergerfs على جهاز ZimaCube الخاص به. وحدد النقاش لاحقًا أن النسخة الأساسية كانت قديمة، لذا فإن وجودها لا يضمن التوافق مع إعداد حديث.
هل اختُبر استرداد SnapRAID بالكامل؟
لا. تحقق الاختبار المضبوط من التثبيت ومن مجموعة mergerfs مؤقتة، لكنه توقف صراحةً قبل إجراء اختبار كامل لتكافؤ SnapRAID والاستعادة.
لماذا لم يكن انتظار فشل الخدمة كافيًا؟
كان من الممكن أن تؤدي إحدى حالتي التنافس إلى إنشاء مجموعة فارغة مع رمز خروج يشير إلى النجاح. ولأن ذلك لا يُعد فشلًا، فقد تفوّت قاعدة إعادة التشغيل عند الفشل هذه الحالة وحدها.
