هذا المصدر أقوى من شكوى عامة من نوع «الأقراص لديّ لا تدخل في وضع السكون مطلقًا»، لأن IceWhale استجابت بخطة لإصلاح المنتج وبطريقة لتشخيص المشكلة. ظلت أقراص HDD الستة التي تعمل بتكوين RAID5 نشطة حتى بعد إيقاف تطبيقات Docker، لذلك انتقل التحقيق إلى خدمات التخزين/الصحة في ZimaOS وإلى احتمال وجود نشاط على مستوى النواة.
عمل الإصدار ZimaOS 1.3.2 على تقليل الاستعلامات غير الضرورية عن الأقراص وتحسين سلوك وضع الاستعداد. وبعد ذلك بوقت طويل، أصلح الإصدار ZimaOS 1.6.0 مشكلة محددة أخرى كان فيها smartd يوقظ الأقراص الساكنة بشكل متقطع. تعالج هذه الإصدارات مصادر الاستيقاظ المعروفة، لكن القرص الحالي الذي لا يزال نشطًا قد يكون قيد الوصول من تطبيق آخر أو خدمة نسخ احتياطي أو مفهرس أو مهمة لنظام الملفات أو جسر USB أو خدمة من خدمات النواة.
غيّرت IceWhale آلية استطلاع التخزين في ZimaOS 1.3.2
وصف orca-zhang ثلاثة تحسينات محددة مخططًا لها في الإصدار 1.3.2:
- تبسيط منطق فحص الصحة؛
- تحديث ذاكرة التخزين المؤقت لبيانات القرص فقط عند اكتشاف تغيير في القرص؛
- التوقف عن محاولة جلب معلومات مثل درجة الحرارة أو مدة التشغيل من قرص موجود أصلًا في وضع الاستعداد.
والسبب مهم: بعض أقراص HDD أو وحدات التحكم لا تستطيع الإجابة عن هذه الاستعلامات من ذاكرة التخزين المؤقت، لذلك قد يؤدي طلب بيانات الصحة إلى إيقاظ القرص فعليًا.
تلخص ملاحظات إصدار 1.3.2 الحالية هذا العمل بأنه تقليل لنشاط القراءة/الكتابة غير الضروري وتحسين لوضع استعداد القرص.
وفّرت IceWhale استعلامًا لمعرفة العمليات التي تصل إلى القرص
اقترح الرد الرسمي من المصدر تحديد العمليات التي لديها حاليًا نظام ملفات أو جهاز مفتوح:
for pid in $(fuser -m <device_path> 2>/dev/null); do
ps -p $pid -o comm=
done | uniqاستبدل <device_path> بالمسار الفعلي للقرص أو وحدة التخزين المركبة. هذا إجراء تشخيصي وليس إجراءً تدميريًا.
اقترحت IceWhale أيضًا إيقاف خدمات التخزين/الملفات مؤقتًا
لاستكشاف المشكلة، اقترح المصدر اختبار وضع الاستعداد بعد إيقاف:
systemctl stop zimaos-local-storage
systemctl stop icewhale-filesحذّرت IceWhale من أن أجزاءً من «الإعدادات» و«الملفات» ستتوقف عن العمل أثناء توقف هذه الخدمات. استخدم ذلك كإجراء تشخيصي مضبوط فقط، ثم أعد تشغيل الخدمات أو أعد تشغيل الجهاز.
أصلح ZimaOS 1.6.0 مصدرًا معروفًا آخر لإيقاظ الأقراص
أضاف سجل تغييرات الإصدار 1.6.0 الرسمي لاحقًا إصلاحًا منفصلًا: إذ تعذر على الأقراص الدخول في وضع السكون العادي لأن خدمة smartd كانت توقظها بشكل متقطع.
راجع إصلاح وضع الاستعداد الرسمي الخاص بـ smartd.
نقل AppData إلى NVMe لا يضمن بقاء أقراص HDD خاملة
كان مستخدم المصدر قد نقل قواعد بيانات Docker إلى NVMe بالفعل. ومع ذلك، قد تتعرض أقراص HDD للوصول بسبب فحص الوسائط أو النسخ الاحتياطي أو الصور المصغرة أو عملاء SMB أو فحوصات SMART أو مهام RAID/التكافؤ أو فهرسة «الملفات» أو عملية تُبقي مسارًا مفتوحًا.
استخدم أدلة فعلية على الوصول بدلًا من افتراض أن وجود جميع التطبيقات على NVMe يعني عدم وجود أي إدخال/إخراج على المصفوفة.
قد يضيف RAID5 نشاطًا خلفيًا خاصًا به
يمكن لفحوصات التكافؤ وإعادة البناء وعمليات التنظيف ونشاط بيانات نظام الملفات الوصفية والمراقبة أن تصل بشكل مشروع إلى كل عضو في المصفوفة. تأكد من أن RAID لا ينفذ عملية صيانة طويلة قبل تشخيص مشكلة وضع الاستعداد.
ينبغي اختبار ZimaOS الحالي قبل تطبيق حلول الخدمات القديمة
الإصدار الحالي من ZimaOS هو 1.7.1، ويتضمن سنوات من التغييرات في إدارة التخزين بعد هذا التقرير المنشور في يناير 2025. أعد إنتاج المشكلة أولًا على الإصدار الحالي، ثم حدد مصدر الاستيقاظ. لا تعطل خدمات الصحة/التخزين بشكل دائم لمجرد إجبار الأقراص على التوقف عن الدوران.
الأسئلة الشائعة حول وضع استعداد القرص
هل أقرت IceWhale بوجود مشكلة وضع الاستعداد في المصدر؟
نعم. قال فريق العمل إن المشكلة قيد التحقيق، ووثّق تحسينات الإصدار 1.3.2.
هل يمكن أن يؤدي التحقق من درجة حرارة القرص أو صحته إلى إيقاظ بعض الأقراص؟
نعم. ذكرت IceWhale تحديدًا أن بعض الأقراص التي لا تتوفر لها معلومات مخزنة مؤقتًا قد تستيقظ عند الاستعلام عنها.
هل تم تحديد smartd لاحقًا باعتباره مصدرًا آخر لإيقاظ الأقراص؟
نعم. أصلح ZimaOS 1.6.0 صراحةً عمليات الإيقاظ المتقطعة التي كانت تنفذها smartd وتمنع السكون العادي.
