الخلاصة: إذا كانت RAID تعمل لكن ZimaOS يقول إن أقراص NVMe مفقودة، فاشتبه في تعيين المنافذ قبل تعطل القرص
في عدة عمليات تثبيت على أجهزة Beelink ME Mini، ظل تخزين RAID 0/5 قابلًا للقراءة والكتابة عبر SMB، بينما عرضت لوحة المعلومات أقراص NVMe مفقودة أو معلومات غير صحيحة عن المساحة الحرة. ويعني هذا النمط أن Linux وطبقة RAID تستطيعان بالفعل رؤية الأجهزة. أما الطبقة المعطّلة فهي تعيين المنافذ الفعلية وواجهة مستخدم ZimaOS.
أثبت أولًا سلامة NVMe وRAID خلف واجهة المستخدم
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
lspci | grep -i "Non-Volatile"
cat /proc/mdstat
df -hإذا كانت RAID موصّلة، وكان SMB يعمل، وظهرت أجهزة NVMe المتوقعة في lspci/lsblk، ولا تُعد إنشاء المصفوفة لمجرد إصلاح لوحة المعلومات. صُممت شاشات التخزين الحالية في ZimaOS لعرض حالة القرص والسعة ومعلومات القراءة/الكتابة بمجرد تصحيح التعيين.
يوفّر حالة تخزين ZimaOS النتيجة النهائية المتوقعة.
يستخدم تعيين NVMe عناوين PCI، وليس HCTL الخاص بـ lsblk
استخدم الإصلاح القديم للأجهزة غير التابعة لـ Zima lspci لأجهزة NVMe. lsblk -o hctl وهو فرع SATA/SCSI، وقد لا يعيد أي نتائج مفيدة لأجهزة NVMe. وقد أزال هذا التمييز الالتباس في النقاش.
الإصلاح التاريخي لملف local-storage.conf
الحل البديل من IceWhale للأجهزة غير التابعة لـ Zima استخدم /etc/casaos/local-storage.conf وحدّث الملف NVMe الربط بما يطابق عناوين PCI التي تم الكشف عنها بواسطة lspci، متبوعًا بـ:
systemctl restart zimaos-local-storageاكتشف المستخدمون لاحقًا أن سلوك المحلل الفعلي في إصداراتهم يتطلب عناوين مفصولة بمسافات بدلًا من المثال المفصول بفواصل المنشور أصلًا. ونظرًا إلى أن هذا حل بديل قديم منخفض المستوى، خذ نسخة احتياطية من الإعدادات وفضّل سلوك ZimaOS الحالي أولًا قبل تعديلها يدويًا.
يحافظ ربط الأقراص غير التابعة لـ Zima على الإجراء التاريخي.
كيف تبدو واجهة NVMe المصححة
بعد تصحيح الربط، يمكن للوحة المعلومات عرض طراز كل قرص SSD وسعته ودرجة حرارته ونسبة استخدامه بدلًا من بطاقات الأقراص المفقودة الوهمية. يغيّر الإصلاح طريقة ربط ZimaOS لأجهزة PCI الفعلية بالمنافذ المرئية؛ ولا يصلح بيانات نظام الملفات.
كيفية التحقق من صحة NVMe بشكل مستقل عن الواجهة
nvme list
nvme smart-log /dev/nvme0
smartctl -a /dev/nvme0يوفر فحوصات صحة nvme-cli أدوات NVMe القياسية لنظام Linux. استخدمها عندما تكون لوحة المعلومات موضع شك، لكنك لا تزال بحاجة إلى أدلة على صحة محرك الأقراص.
متى ينبغي ألّا تعدّل خريطة الفتحات
إذا كان جهاز NVMe غير موجود في lspci و lsblk، فأنت لا تواجه مشكلة تقتصر على الواجهة. تحقّق أولًا من BIOS، وتركيب محرك الأقراص، وبروتوكول الفتحة، والطاقة، وتوافق الأجهزة. لا يمكن لتعديل خريطة الفتحات أن يجعل محرك أقراص غير مكتشف فعليًا يظهر.
يوفر تخزين ZimaCube 2 واسترداد RAID بنيات مرجعية أكثر أمانًا.
الأسئلة الشائعة
لماذا تعمل مصفوفة RAID على Beelink بينما يعرض ZimaOS أقراصًا مفقودة؟
يمكن لنظام Linux تجميع RAID وتركيبه حتى إذا لم تتطابق خريطة الفتحات المرئية في ZimaOS مع طوبولوجيا PCI الخاصة بـ Beelink.
هل ينبغي إعادة إنشاء RAID لإصلاح بطاقات NVMe المفقودة؟
لا. إذا كانت البيانات قابلة للقراءة والمصفوفة سليمة، فأصلح ربط الواجهة أو أبلغ عنه بدلًا من تدمير مصفوفة عاملة.
لماذا لا يعرض lsblk -o hctl أي شيء؟
أجهزة NVMe هي أجهزة PCIe، وكان الحل البديل القديم يستخدم عناوين lspci. أما HCTL فهو أكثر صلة بربط الأجهزة بنمط SCSI/SATA.
هل لا يزال بإمكاني استخدام nvme-cli إذا كانت واجهة ZimaOS غير صحيحة؟
نعم، إذا كان الجهاز ظاهرًا لنظام Linux. يمكن للأمر nvme smart-log توفير معلومات الصحة ودرجة الحرارة وعدادات الأخطاء بشكل مستقل عن لوحة المعلومات.
هل لا يزال تعديل local-storage.conf هو الخطوة الأولى الموصى بها؟
لا. هذا حلّ بديل تاريخي للأجهزة غير التابعة لـ Zima. اختبر الإصدار الحالي أولًا واحتفظ بنسخة احتياطية من الإعدادات قبل إجراء تعديلات يدوية.
