MDMON(8) System Manager's Manual MDMON(8)

mdmon - نظارت بر آرایه‌های دارای متادیتای خارجی MD

mdmon [--all] [--takeover] [--foreground] CONTAINER

هستهٔ ۲.۶.۲۷ قابلیت پشتیبانی از آرایه‌های دارای متادیتای خارجی را به همراه دارد. متادیتای خارجی بدین معناست که فضای کاربری تمام به‌روزرسانی‌های متادیتا را مدیریت می‌کند. مسئولیت هسته این است که هنگام وقوع یک «رویداد متادیتا» مانند خرابی دیسک‌ها و گذار از حالت پاک به کثیف (clean-to-dirty transitions)، به فضای کاربری اطلاع دهد. هسته در موارد مهم منتظر می‌ماند تا فضای کاربری در قبال این اعلان‌ها اقدام لازم را انجام دهد.

برای پاسخ‌گویی به درخواست‌های به‌روزرسانی متادیتا، یک دیمن به نام mdmon معرفی شده است. Mdmon وظیفه دارد فضای نام sysfs را برای بررسی تغییرات در مشخصه‌های array_state، sync_action و مشخصهٔ state مربوط به هر دیسک پایش (poll) کند. زمانی که تغییری شناسایی شود، گردانندهٔ مخصوص آن نوع متادیتا را فرامی‌خواند تا تغییرات لازم را در متادیتا اعمال کند. اقدامات زیر انجام می‌شوند:

پاک کردن بیت کثیف (dirty bit) برای این حجم و اجازه دادن به توقف آرایه
تنظیم بیت کثیف برای آرایه و سپس تنظیم array_state به active. عملیات‌های نوشتن مسدود می‌شوند تا زمانی که فضای کاربری مقدار active را بنویسد.
تایمر حالت امن منقضی شده است، بنابراین وضعیت آرایه روی clean تنظیم می‌شود تا نوشتن روی آرایه مسدود شود
پاک کردن بیت کثیف برای این حجم
این وضعیت اولیه‌ای است که همه آرایه‌ها در آن شروع به کار می‌کنند. mdmon یکی از سه اقدام زیر را انجام می‌دهد:
1/
انتقال آرایه به حالت read-auto و پاک نگه داشتن بیت کثیف در صورتی که گردانندهٔ متادیتا تشخیص دهد آرایه نیازی به همگام‌سازی مجدد (resync) یا تغییر دیگری ندارد
2/
انتقال آرایه به حالت active در صورتی که گردانندهٔ متادیتا تشخیص دهد همگام‌سازی مجدد یا دستکاری دیگری لازم است
3/
باقی گذاشتن آرایه در حالت read-only در صورتی که حجم علامت‌گذاری شده باشد که نباید پایش شود؛ برای نمونه، نسخهٔ متادیتا به جای "external:/dev/md127" روی "external:-dev/md127" تنظیم شده باشد
به گردانندهٔ متادیتا اطلاع می‌دهد که ممکن است یک فرایند همگام‌سازی مجدد تکمیل شده باشد. اگر یک فرایند همگام‌سازی مجدد پیش از تکمیل شدن متوقف (idle) شود، این رویداد به گردانندهٔ متادیتا امکان می‌دهد یک نقطهٔ بازرسی (checkpoint) برای همگام‌سازی مجدد ثبت کند.
ممکن است بازسازی یک دیسک یدکی (spare) به پایان رسیده باشد، بنابراین وضعیت هر دیسک را به گردانندهٔ متادیتا اطلاع می‌دهد. این فرصتی برای گردانندهٔ متادیتا است تا هرگونه بیت "out-of-sync" (ناهمگام) را پاک کرده و وضعیت تخریب‌شدهٔ (degraded) حجم را رفع کند. اگر یک فرایند بازیابی پیش از تکمیل شدن متوقف شود، این رویداد به گردانندهٔ متادیتا امکان می‌دهد یک نقطهٔ بازرسی برای بازیابی ثبت کند.
<disk>/state - faulty
خرابی یک دیسک زنجیره‌ای از رویدادها را آغاز می‌کند. نخست، به گردانندهٔ متادیتا اطلاع داده می‌شود که یک دیسک خراب شده است، و سپس به هسته اطلاع داده می‌شود که می‌تواند عملیات‌های نوشتنی را که وابسته به این دیسک بودند از حالت مسدود خارج کند. پس از رفع انسداد توسط هسته، این دیسک برای «حذف‌شده+» (+removed) از آرایهٔ عضو تعیین می‌شود. در نهایت، دیسک در تمامی دیگر آرایه‌های عضو موجود در کانتینر به عنوان خراب علامت‌گذاری می‌شود.
+ توجه: این رفتار کمی با آرایه‌های بومی MD متفاوت است که در آن‌ها حذف صرفاً برای یک رویداد mdadm --remove رزرو شده است. در حالت متادیتای خارجی، کانتینر آخرین ارجاع به دستگاه بلوکی را نگه می‌دارد و همچنان فراخوانی دستور mdadm --remove <container> <victim> مورد نیاز است.

قالب‌های متادیتای خارجی، مانند DDF، از این جهت با قالب‌های متادیتای بومی MD تفاوت دارند که مجموعه‌ای از دیسک‌ها و یک سری زیرآرایه درون آن دیسک‌ها را تعریف می‌کنند. در مقایسه، متادیتای MD یک رابطهٔ ۱:۱ میان مجموعه‌ای از دستگاه‌های بلوکی و یک آرایهٔ RAID تعریف می‌کند. برای نمونه، جهت ایجاد ۲ آرایه با سطوح مختلف RAID روی یک مجموعه دیسک واحد، متادیتای MD ایجاب می‌کند که دیسک‌ها پارتیشن‌بندی شوند و سپس هر آرایه با زیرمجموعه‌ای از آن پارتیشن‌ها ایجاد گردد. قالب‌های خارجی پشتیبانی‌شده، این تقسیم‌بندی دیسک را به صورت درونی انجام می‌دهند.

دستگاه‌های کانتینر صرفاً ارجاعاتی به تمام دیسک‌های عضو نگه می‌دارند و به ابزارهایی مانند mdmon امکان می‌دهند تشخیص دهند کدام آرایه‌های فعال به کدام کانتینر تعلق دارند. برخی از دستورات مدیریت آرایه مانند حذف دیسک و افزودن دیسک اکنون فقط در سطح کانتینر معتبر هستند. تلاش برای انجام این اقدامات روی آرایه‌های عضو با پیام‌های خطایی مانند زیر مسدود می‌شود:

"mdadm: Cannot remove disks from a ´member´ array, perform this operation on the parent container"

کانتینرها در فایل /proc/mdstat با رشتهٔ نسخهٔ متادیتای "external:<metadata name>" شناسایی می‌شوند. دستگاه‌های عضو با رشتهٔ "external:/<container device>/<member index>"، یا "external:-<container device>/<member index>" در صورتی که آرایه قرار است فقط‌خواندنی باقی بماند، مشخص می‌شوند.

دستگاه container (کانتینر) مورد نظر برای نظارت. این می‌تواند یک مسیر کامل مانند /dev/md/container یا یک نام سادهٔ دستگاه md مانند md127 باشد.
به طور معمول، mdmon منشعب شده (fork) و در پس‌زمینه ادامه می‌دهد. افزودن این گزینه این مرحله را نادیده گرفته و mdmon را در پیش‌زمینه اجرا می‌کند.
این گزینه به mdmon دستور می‌دهد جایگزین هر فرایند فعال mdmon دیگری شود که در حال حاضر بر آرایه نظارت می‌کند. این ویژگی اساساً در اواخر فرایند بوت برای جایگزینی هر mdmon که پیش از سوار شدن فایل‌سیستم ریشه از یک initramfs راه‌اندازی شده بود به کار می‌رود. این کار از نگه داشتن طولانی‌مدت ارجاع روی آن initramfs جلوگیری کرده و اطمینان می‌دهد که فایل‌های pid و sock مورد استفاده برای ارتباط با mdmon در یک مکان استاندارد قرار دارند.
این گزینه به mdmon دستور می‌دهد که هر کانتینر فعالی را بیابد و در صورت مناسب بودن، نظارت بر هر یک از آن‌ها را آغاز کند. این گزینه معمولاً همراه با --takeover در اواخر توالی بوت استفاده می‌شود. برای هر کانتینر یک فرایند مجزای mdmon راه‌اندازی می‌شود چرا که آرگومان --all با نام کانتینر جایگزین (بازنویسی) می‌شود. برای فراهم کردن امکان کانتینرهایی با نام‌های طولانی‌تر از ۵ نویسه، این آرگومان را می‌توان به دلخواه گسترش داد، برای نمونه به --all-active-arrays.

توجه داشته باشید که mdmon در صورت نیاز به طور خودکار توسط mdadm راه‌اندازی می‌شود و بنابراین هنگام کار با آرایه‌های RAID نیازی به در نظر گرفتن مستقیم آن نیست. تنها مواقعی که این ابزار به جز توسط mdadm اجرا می‌شود، زمانی است که اسکریپت‌های بوت نیاز دارند پس از سوار کردن فایل‌سیستم ریشهٔ جدید، آن را مجدداً راه‌اندازی کنند.

از آنجا که mdmon باید هر زمان که هر فایل‌سیستمی روی دستگاهِ تحت نظارت سوار شده است در حال اجرا باشد، هنگامی که فایل‌سیستم ریشه از روی یک دستگاهِ تحت نظارت mdmon سوار می‌شود ملاحظات ویژه‌ای وجود دارد. توجه داشته باشید که به طور کلی mdmon حتی در صورت سوار شدن فایل‌سیستم به صورت فقط‌خواندنی نیز مورد نیاز است، زیرا برخی از فایل‌سیستم‌ها تحت آن شرایط همچنان می‌توانند روی دستگاه بنویسند؛ برای نمونه جهت بازپخش ژورنال پس از یک خاموش‌سازی ناگهانی (unclean shutdown).

هنگامی که آرایه توسط کد initramfs سرهم‌بندی می‌شود، mdadm در صورت نیاز به طور خودکار mdmon را راه‌اندازی خواهد کرد. این بدان معناست که mdmon باید روی initramfs نصب شده باشد و باید یک فایل‌سیستم قابل نوشتن (معمولاً tmpfs) وجود داشته باشد که در آن mdmon بتواند فایل‌های .pid و .sock را ایجاد کند. فایل‌سیستم مشخص برای استفاده در زمان کامپایل به mdmon داده می‌شود و پیش‌فرض آن /run/mdadm است.

این فایل‌سیستم باید تا زمان خاموش‌سازی پایدار بماند.

پس از آنکه فایل‌سیستم ریشهٔ نهایی مستقر شد (معمولاً با pivot_root)، mdmon باید با گزینه‌های --all --takeover اجرا شود تا mdmon در حال اجرا از initramfs بتواند با یک نمونهٔ در حال اجرا در ریشهٔ اصلی جایگزین شود، و بدین ترتیب حافظهٔ مورد استفاده توسط initramfs آزاد گردد.

در زمان خاموش‌سازی، mdmon نباید همراه با سایر فرایندها خاتمه داده شود (kill شود). همچنین از آنجا که یک فایل (در واقع سوکت) را در /dev (به طور پیش‌فرض) باز نگه می‌دارد، در صورتی که /dev یک فایل‌سیستم مجزا باشد، پیاده کردن (unmount) آن امکان‌پذیر نخواهد بود.

mdmon --all-active-arrays --takeover
هر فرایند mdmon که در حال حاضر در حال اجرا است خاتمه داده می‌شود و یک نمونهٔ جدید راه‌اندازی می‌گردد. در صورتی که از یک initramfs استفاده شده باشد، این دستور باید در طول توالی بوت اجرا شود، تا هیچ mdmon در حال اجرایی از initramfs، آن initramfs را فعال نگه ندارد.

mdadm(8), md(4).

v4.6