فایل سیستم های مجازی در لینوکس: چرا به آنها نیاز است و چگونه کار می کنند؟ قسمت 2

سلام به همه، قسمت دوم نشریه «سیستم های فایل مجازی در لینوکس: چرا به آنها نیاز است و چگونه کار می کنند؟» را با شما به اشتراک می گذاریم. می توانید قسمت اول را بخوانید اینجا. یادآوری می کنیم که این سری از انتشارات همزمان با راه اندازی یک جریان جدید در این دوره است. "مدیر لینوکس"، که خیلی زود شروع می شود.

نحوه نظارت بر VFS با استفاده از ابزارهای eBPF و bcc

ساده ترین راه برای درک چگونگی عملکرد هسته روی فایل ها sysfs دیدن آن در عمل است و ساده ترین راه برای تماشای ARM64 استفاده از eBPF است. eBPF (مخفف فیلتر بسته برکلی) شامل یک ماشین مجازی است که در آن کار می کند هسته، که کاربران ممتاز می توانند درخواست کنند (query) از خط فرمان. منابع هسته به خواننده می گویند که هسته چه کاری می تواند انجام دهد. اجرای ابزارهای eBPF بر روی یک سیستم بارگذاری شده نشان می دهد که هسته در واقع چه کاری انجام می دهد.

فایل سیستم های مجازی در لینوکس: چرا به آنها نیاز است و چگونه کار می کنند؟ قسمت 2

خوشبختانه، شروع استفاده از eBPF با کمک ابزارها بسیار آسان است BCC، که به صورت بسته از توزیع عمومی موجود هستند لینـوکــس و با جزئیات مستند شده است برنارد گرگ. ابزار bcc اسکریپت های پایتون با درج های کوچکی از کد C هستند، به این معنی که هر کسی که با هر دو زبان آشنا باشد می تواند به راحتی آنها را تغییر دهد. که در bcc/tools 80 اسکریپت پایتون وجود دارد، به این معنی که به احتمال زیاد یک توسعه دهنده یا مدیر سیستم می تواند چیزی مناسب برای حل مشکل انتخاب کند.
برای اینکه حداقل یک ایده سطحی از کار VFS ها روی یک سیستم در حال اجرا داشته باشید، سعی کنید vfscount یا vfsstat. این نشان می دهد، فرض کنید، ده ها تماس vfs_open() و "دوستان او" به معنای واقعی کلمه هر ثانیه اتفاق می افتد.

فایل سیستم های مجازی در لینوکس: چرا به آنها نیاز است و چگونه کار می کنند؟ قسمت 2

vfsstat.py یک اسکریپت پایتون با درج کد C است که به سادگی فراخوانی های تابع VFS را می شمارد.

بیایید مثال بی اهمیت تری بزنیم و ببینیم وقتی یک درایو فلش USB را در رایانه قرار می دهیم و سیستم آن را تشخیص می دهد چه اتفاقی می افتد.

فایل سیستم های مجازی در لینوکس: چرا به آنها نیاز است و چگونه کار می کنند؟ قسمت 2

با استفاده از eBPF می توانید آنچه را که در آن اتفاق می افتد مشاهده کنید /sysهنگامی که یک درایو فلش USB وارد می شود. یک مثال ساده و پیچیده در اینجا نشان داده شده است.

در مثال نشان داده شده در بالا، bcc ابزار trace.py هنگامی که دستور اجرا می شود پیامی را چاپ می کند sysfs_create_files(). ما آن را می بینیم sysfs_create_files() با استفاده راه اندازی شد kworker استریم در پاسخ به اینکه فلش درایو قرار داده شده است، اما چه فایلی ایجاد شده است؟ مثال دوم قدرت eBPF را نشان می دهد. اینجا trace.py یک بک‌تریس هسته (گزینه -K) و نام فایلی که ایجاد شده است را چاپ می‌کند sysfs_create_files(). درج عبارت منفرد کد C است که شامل یک رشته فرمت به راحتی قابل تشخیص است که توسط اسکریپت پایتون ارائه شده است که LLVM را اجرا می کند. کامپایلر به موقع. این خط را کامپایل کرده و در ماشین مجازی داخل هسته اجرا می کند. امضای عملکرد کامل sysfs_create_files () باید در دستور دوم بازتولید شود تا رشته قالب بتواند به یکی از پارامترها اشاره کند. خطاهای این قطعه کد C منجر به خطاهای قابل تشخیص از کامپایلر C می شود. به عنوان مثال، اگر پارامتر -l حذف شود، "کامپایل متن BPF ناموفق بود" را مشاهده خواهید کرد. توسعه دهندگانی که با C و Python آشنا هستند ابزارها را پیدا خواهند کرد bcc آسان برای گسترش و تغییر.

هنگامی که درایو USB وارد می شود، بک تریس هسته نشان می دهد که PID 7711 یک رشته است. kworkerکه فایل را ایجاد کرد «events» в sysfs. بر این اساس، تماس از sysfs_remove_files() نشان می دهد که حذف درایو منجر به حذف فایل شده است events، که با مفهوم کلی شمارش مرجع مطابقت دارد. در عین حال مشاهده sysfs_create_link () با eBPF هنگام قرار دادن درایو USB نشان می دهد که حداقل 48 پیوند نمادین ایجاد شده است.

پس فایل رویدادها چه فایده ای دارد؟ استفاده cscope برای جستجو __device_add_disk()، نشان می دهد که چه چیزی باعث می شود disk_add_events ()، و یا "media_change"یا "eject_request" را می توان در یک فایل رویداد ثبت کرد. در اینجا لایه بلوک هسته به فضای کاربران اطلاع می دهد که یک "دیسک" ظاهر و خارج شده است. توجه داشته باشید که این روش تحقیق با قرار دادن درایو USB چقدر آموزنده است، در مقایسه با تلاش برای فهمیدن اینکه چگونه کارها صرفاً از منبع کار می کنند.

سیستم های فایل ریشه فقط خواندنی دستگاه های جاسازی شده را فعال می کنند

البته هیچکس با کشیدن دوشاخه از پریز، سرور یا کامپیوتر خود را خاموش نمی کند. اما چرا؟ این به این دلیل است که سیستم‌های فایل نصب‌شده روی دستگاه‌های ذخیره‌سازی فیزیکی ممکن است نوشتن با تأخیر داشته باشند، و ساختارهای داده‌ای که وضعیت آن‌ها را ثبت می‌کنند ممکن است با نوشته‌های ذخیره‌سازی همگام‌سازی نشوند. هنگامی که این اتفاق می افتد، صاحبان سیستم باید تا راه اندازی بعدی منتظر بمانند تا ابزار را راه اندازی کنند. fsck filesystem-recovery و در بدترین حالت، از دست دادن اطلاعات.

با این حال، همه ما می دانیم که بسیاری از دستگاه های اینترنت اشیا، و همچنین روترها، ترموستات ها و اتومبیل ها، اکنون لینوکس را اجرا می کنند. بسیاری از این دستگاه‌ها رابط کاربری کمی دارند و هیچ راهی برای خاموش کردن «تمیز» آنها وجود ندارد. تصور کنید وقتی برق واحد کنترل قطع است، ماشینی را با باتری خاموش روشن کنید لینـوکــس مدام بالا و پایین می پرید چگونه است که سیستم بدون طولانی بوت می شود fsckموتور بالاخره کی شروع به کار میکنه؟ و پاسخ ساده است. دستگاه های جاسازی شده به سیستم فایل ریشه متکی هستند فقط برای خواندن (خلاصه ro-rootfs (سیستم فایل روت فقط خواندنی)).

ro-rootfs مزایای بسیاری را ارائه می دهد که کمتر از اصالت آشکار است. یک مزیت این است که بدافزار نمی تواند در آن بنویسد /usr یا /lib، اگر هیچ فرآیند لینوکس نمی تواند در آنجا بنویسد. مورد دیگر این است که یک سیستم فایل تا حد زیادی تغییر ناپذیر برای پشتیبانی میدانی از دستگاه های راه دور حیاتی است، زیرا پرسنل پشتیبانی به سیستم های محلی که اسماً با سیستم های میدانی یکسان هستند، متکی هستند. شاید مهم ترین (اما موذی ترین) مزیت این باشد که ro-rootfs توسعه دهندگان را مجبور می کند تصمیم بگیرند که کدام اشیاء سیستم در مرحله طراحی سیستم تغییرناپذیر خواهد بود. کار با ro-rootf ها می تواند ناخوشایند و دردناک باشد، زیرا متغیرهای const اغلب در زبان های برنامه نویسی هستند، اما مزایای آنها به راحتی هزینه های اضافی را توجیه می کند.

ایجاد rootfs فقط خواندنی نیاز به تلاش بیشتری برای توسعه دهندگان تعبیه شده دارد و اینجاست که VFS به چشم می خورد. لینوکس نیاز دارد که فایل‌ها داخل باشند /var قابل نوشتن بودند، و علاوه بر این، بسیاری از برنامه های کاربردی محبوب که سیستم های تعبیه شده را اجرا می کنند، سعی در ایجاد پیکربندی دارند. dot-files в $HOME. یک راه حل برای فایل های پیکربندی در دایرکتوری خانگی معمولاً تولید و ساخت آنها در داخل آن است rootfsاست. برای /var یک روش ممکن این است که آن را بر روی یک پارتیشن قابل نوشتن جداگانه نصب کنید، در حالی که / نصب شده فقط خواندنی یکی دیگر از جایگزین های محبوب استفاده از پایه های اتصال یا روکش است.

پایه های قابل اتصال و انباشته شدن، استفاده از آنها توسط کانتینرها

اجرای دستور man mount بهترین راه برای یادگیری در مورد مانت های قابل اتصال و همپوشانی است که به توسعه دهندگان و مدیران سیستم این امکان را می دهد که یک سیستم فایل را در یک مسیر ایجاد کنند و سپس آن را در معرض برنامه های دیگر قرار دهند. برای سیستم های جاسازی شده، این به معنای توانایی ذخیره فایل ها در آن است /var در یک درایو فلش فقط خواندنی، اما یک مسیر نصب همپوشانی یا قابل پیوند از tmpfs в /var هنگام بارگذاری، به برنامه‌ها اجازه می‌دهد تا یادداشت‌ها را در آنجا بنویسند (خراش). دفعه بعد که تغییرات را روشن کردید /var گم خواهد شد. یک مانت روکش یک اتحاد بین ایجاد می کند tmpfs و سیستم فایل زیرین و به شما امکان می دهد تغییرات ظاهری را در فایل های موجود در آن ایجاد کنید ro-tootf در حالی که یک مانت قابل اتصال می تواند موارد جدید را خالی کند tmpfs پوشه های قابل نوشتن در داخل قابل مشاهده است ro-rootfs راه ها. در حالی که overlayfs این درست است (proper) نوع سیستم فایل، mount قابل اتصال در آن پیاده سازی شده است فضای نام VFS.

بر اساس توضیحات مربوط به همپوشانی و اتصال قابل اتصال، هیچ کس تعجب نمی کند کانتینرهای لینوکس آنها به طور فعال مورد استفاده قرار می گیرند. بیایید ببینیم هنگام استفاده چه اتفاقی می افتد systemd-nspawn برای اجرای ظرف با استفاده از ابزار mountsnoop از bcc.

تماس بگیرید system-nspawn ظرف را در حین کار روشن می کند mountsnoop.py.

ببینیم چی شد:

راه اندازی mountsnoop در حالی که کانتینر در حال "بوت شدن" است نشان می دهد که زمان اجرای کانتینر به شدت به اتصال متصل شده بستگی دارد (فقط ابتدای خروجی طولانی نشان داده شده است).

اینجا systemd-nspawn فایل های انتخابی را در آن ارائه می کند procfs и sysfs میزبان به ظرف به عنوان مسیرهایی به آن rootfs... بعلاوه MS_BIND پرچمی که پایه اتصال را تنظیم می‌کند، برخی پرچم‌های دیگر روی مانت رابطه بین تغییرات میزبان و فضای نام کانتینر را تعریف می‌کنند. به عنوان مثال، یک mount مرتبط می‌تواند از تغییرات آن صرفنظر کند /proc и /sys داخل ظرف، یا بسته به تماس آنها را پنهان کنید.

نتیجه

درک عملکرد درونی لینوکس می‌تواند کاری غیرممکن به نظر برسد، زیرا خود هسته حاوی مقدار زیادی کد است، برنامه‌های کاربردی فضای کاربر لینوکس و رابط‌های تماس سیستمی در کتابخانه‌های C مانند glibc. یکی از راه‌های پیشرفت، خواندن کد منبع یک زیرسیستم هسته، با تأکید بر درک فراخوانی‌های سیستم و هدرهای فضای کاربر، و همچنین رابط‌های اصلی هسته داخلی، مانند جدول است. file_operations. عملیات فایل اصل "همه چیز یک فایل است" را ارائه می کند و مدیریت آنها را بسیار لذت بخش می کند. فایل های منبع C در دایرکتوری سطح بالا fs/ ارائه یک پیاده سازی از سیستم های فایل مجازی، که یک لایه پوششی هستند که سازگاری گسترده و نسبتا ساده ای را بین سیستم های فایل محبوب و دستگاه های ذخیره سازی فراهم می کند. پیوند دادن و نصب هم‌پوشانی از طریق فضاهای نام لینوکس، جادوی VFS است که ایجاد کانتینرهای فقط خواندنی و سیستم‌های فایل ریشه را ممکن می‌سازد. همراه با بررسی کد منبع، ابزار اصلی eBPF و رابط آن bcc
اکتشاف هسته را راحت تر از همیشه می کند.

دوستان بنویسید این مطلب براتون مفید بود؟ شاید شما نظر یا تذکری دارید؟ و از علاقه مندان به دوره مدیریت لینوکس دعوت به عمل می آید روز بازکه در 18 آوریل برگزار می شود.

قسمت اول

منبع: www.habr.com

اضافه کردن نظر