يثبت المصدر أن استبدال عضوي RAID 1 كليهما بأقراص أكبر لا يؤدي تلقائيًا إلى زيادة حجم نظام الملفات القابل للاستخدام. نجح أحد المستخدمين في استبدال قرصين بسعة 500 غيغابايت بقرصين بسعة 1 تيرابايت، واحدًا تلو الآخر، وترك ZimaOS يعيد البناء بعد كل عملية تبديل. عند تلك النقطة، كان كلا العضوين الفعليين بسعة 1 تيرابايت، لكن جهاز RAID ونظام ملفات Btrfs كانا لا يزالان يعرضان سعة 500 غيغابايت القديمة فقط.
على ZimaOS+ 1.5.4، أكمل ذلك المستخدم التوسعة من خلال SSH باستخدام mdadm --grow /dev/md0 --size=max، وانتظروا الاسترداد/إعادة المزامنة الناتجة، ثم شغّلوا أخيرًا btrfs filesystem resize max مقابل نظام الملفات المُحمّل. وأفادوا بأن الواجهة الرسومية و df ثم أظهر السعة الأكبر. وهذا تحقق قوي من المجتمع، لكنه لا يزال إجراءً يدويًا عبر واجهة سطر الأوامر، وليس إجراءً حاليًا من واجهة IceWhale الرسومية.
انسخ بياناتك احتياطيًا قبل بدء توسيع السعة
يحمي RAID 1 من تعطل عضو واحد؛ لكنه لا يحمي من أخطاء المشغّل، أو تلف بيانات تعريف المصفوفة، أو أخطاء نظام الملفات، أو حدوث مشكلة في قرص ثانٍ أثناء إعادة البناء.
استبدل عضوًا واحدًا فقط من أعضاء RAID في كل مرة
- أوقف تشغيل الجهاز؛
- استبدل القرص القديم الأول بالقرص الأكبر؛
- شغّل الجهاز؛
- استخدم ZimaOS Recovery لإعادة البناء؛
- انتظر حتى يكتمل الاسترداد تمامًا.
كرّر العملية للعضو الثاني
فقط بعد اكتمال إعادة البناء الأولى، أوقف المستخدم الجهاز واستبدل القرص الثاني، ثم شغّل الاسترداد من واجهة المستخدم الرسومية مرة أخرى وانتظر اكتماله بالكامل.
في هذه المرحلة، كانت المصفوفة سليمة على جهازين فعليين أكبر حجمًا، لكنها كانت لا تزال مضبوطة على حجم العضو التاريخي.
ثم قام المستخدم من المجتمع بتوسيع مصفوفة mdadm
كان أمر المصدر هو:
sudo mdadm --grow /dev/md0 --size=maxتحققوا من هندسة المصفوفة الجديدة باستخدام mdadm --detail وانتظر اكتمال حالة الاسترداد/إعادة المزامنة الجديدة.
لا تفترض أبدًا أن مصفوفتك هي /dev/md0؛ حدّد المصفوفة الفعلية أولًا.
ثم كان لا بد من توسيع نظام ملفات Btrfs
انتهى المصدر بـ:
sudo btrfs filesystem resize max /your/mounted/filesystemاستخدم مسار Btrfs المُحمّل الفعلي بدلًا من نسخ العنصر النائب حرفيًا.
لماذا كانت هناك حاجة إلى خطوتين لتغيير الحجم
- جهاز Linux md RAID؛
- نظام ملفات Btrfs الموجود فوقه.
يجب أن يعرض كلاهما الحجم الأكبر قبل أن يرى المستخدمون السعة الإضافية.
تعامل مع هذا على أنه إجراء مجتمعي خاص بإصدار معين
شغّل مستخدم المصدر صراحةً ZimaOS+ 1.5.4. وإصدار ZimaOS الحالي أحدث، وقد تتغير سلوكيات إدارة التخزين. قبل تشغيل إجراءات يدوية mdadm --grow في وحدات التخزين الإنتاجية، تحقّق من أن الواجهة لا تزال تفتقر إلى مسار توسعة مدعوم، وفكّر في طلب الإجراء الحالي من دعم IceWhale.
تحقّق من سلامة RAID قبل كل استبدال فعلي
قبل استبدال القرص الأول — ومرة أخرى قبل استبدال القرص الثاني — تأكد من أن المصفوفة سليمة ومتزامنة بالكامل. إن بدء الاستبدال الثاني قبل اكتمال إعادة بناء الأول يزيل التكرار الذي تعتمد عليه أثناء الترقية.
سجّل الأرقام التسلسلية للأعضاء، حتى يتطابق القرص الفعلي الذي تزيله مع العضو المنطقي الذي يعرضه ZimaOS.
يجب أن توفر الأقراص البديلة سعة فعلية كافية
قد تختلف الأقراص المتساوية اسميًا في السعة قليلًا في عدد القطاعات القابلة للاستخدام. وتستخدم التوسعة الأكثر أمانًا أقراصًا بديلة أكبر بوضوح من الأعضاء القدامى، وبحجم لا يقل عن حجم بعضها بعضًا.
إذا كان قرص «1 تيرابايت» الثاني أصغر قليلًا من الأول، فقد لا تتم خطوة توسيع/إعادة بناء md كما هو متوقع.
توقّع أكثر من دورة إعادة مزامنة واحدة
أعاد سير العمل في المصدر بناء المصفوفة بعد الاستبدال الفعلي الأول، ثم بعد الاستبدال الثاني، ودخل بعد ذلك في حالة استرداد/إعادة مزامنة أخرى بعد mdadm --grow. وهذا يعني أن ترقية السعة قد تستغرق وقتًا أطول بكثير من مجرد استبدال قرصين.
أبقِ جهاز NAS متصلًا بمصدر طاقة موثوق، وتجنب عمليات إعادة التشغيل غير الضرورية أثناء كل مرحلة من مراحل الاسترداد.
تحقّق من جهاز الكتل ونظام الملفات في النهاية
بعد تغيير حجم Btrfs النهائي، تحقّق من النتيجة من أكثر من طبقة:
-
mdadm --detail— البنية الهندسية لـ md RAID؛ -
df -hأو أدوات نظام ملفات Btrfs — سعة نظام الملفات القابلة للاستخدام؛ - واجهة تخزين ZimaOS — حجم التجمع المتوقع وحالته السليمة.
إذا ظلت إحدى الطبقات تعرض الحجم القديم، فتوقف وتحقق بدلًا من تكرار أوامر التوسعة عشوائيًا.
الأسئلة الشائعة حول توسيع RAID 1
هل يمكن لقرص واحد أكبر أن يزيد سعة RAID1 فورًا؟
لا. تظل المرآة مقيدة بالعضو الأصغر وبالبنية الهندسية التاريخية للمصفوفة.
هل أدى استبدال القرصين الأصغر تلقائيًا إلى زيادة السعة في المصدر؟
لا. كان لا يزال يتعين على المستخدم توسيع مصفوفة md ثم تغيير حجم Btrfs.
هل تم تأكيد مصدر سير عمل التوسعة اليدوية؟
نعم، بواسطة أحد مستخدمي ZimaOS+ 1.5.4. ولم تُنشر باعتبارها إجراءً رسميًا من IceWhale.
