لینکس میں ورچوئل فائل سسٹم: ان کی ضرورت کیوں ہے اور وہ کیسے کام کرتے ہیں؟ حصہ 2

سب کو ہیلو، ہم آپ کے ساتھ اشاعت کا دوسرا حصہ شیئر کر رہے ہیں "Linux میں ورچوئل فائل سسٹم: ان کی ضرورت کیوں ہے اور وہ کیسے کام کرتے ہیں؟" آپ پہلا حصہ پڑھ سکتے ہیں۔ یہاں. آئیے آپ کو یاد دلاتے ہیں کہ اشاعتوں کا یہ سلسلہ کورس پر ایک نئے سلسلے کے آغاز کے ساتھ موافق ہے۔ "لینکس ایڈمنسٹریٹر"، جو بہت جلد شروع ہوتا ہے۔

eBPF اور bcc ٹولز کا استعمال کرتے ہوئے VFS کی نگرانی کیسے کریں۔

یہ سمجھنے کا سب سے آسان طریقہ ہے کہ دانا فائلوں پر کیسے کام کرتا ہے۔ sysfs اسے عملی طور پر دیکھنا ہے، اور ARM64 دیکھنے کا سب سے آسان طریقہ eBPF استعمال کرنا ہے۔ ای بی پی ایف (برکلے پیکٹ فلٹر کے لیے مختصر) ایک ورچوئل مشین پر مشتمل ہے لازمی، جو مراعات یافتہ صارفین درخواست کر سکتے ہیں (query) کمانڈ لائن سے۔ دانا کے ذرائع قاری کو بتاتے ہیں کہ دانا کیا کر سکتا ہے۔ بھری ہوئی سسٹم پر ای بی پی ایف ٹولز کو چلانے سے پتہ چلتا ہے کہ دانا اصل میں کیا کر رہا ہے۔

خوش قسمتی سے، ٹولز کی مدد سے ای بی پی ایف کا استعمال شروع کرنا کافی آسان ہے۔ بی سی سی، جو عام تقسیم سے پیکجز کے طور پر دستیاب ہیں۔ لینکس اور تفصیل سے دستاویزی برنارڈ گریگ. اوزار bcc سی کوڈ کے چھوٹے اندراج کے ساتھ پائتھون اسکرپٹ ہیں، جس کا مطلب ہے کہ دونوں زبانوں سے واقف کوئی بھی ان میں آسانی سے ترمیم کرسکتا ہے۔ میں bcc/tools Python کی 80 اسکرپٹس ہیں، جس کا مطلب ہے کہ زیادہ تر امکان ہے کہ کوئی ڈویلپر یا سسٹم ایڈمنسٹریٹر اس مسئلے کو حل کرنے کے لیے کسی مناسب چیز کا انتخاب کر سکے گا۔
کم از کم سطحی خیال حاصل کرنے کے لیے کہ VFS چلتے ہوئے سسٹم پر کیا کام کرتے ہیں، کوشش کریں۔ vfscount یا vfsstat. یہ دکھائے گا، آئیے کہتے ہیں، کہ درجنوں کالز vfs_open() اور "اس کے دوست" لفظی طور پر ہر سیکنڈ میں ہوتے ہیں۔

vfsstat.py ایک Python اسکرپٹ ہے جس میں C کوڈ داخل ہوتا ہے جو صرف VFS فنکشن کالز کو شمار کرتا ہے۔

آئیے ایک اور معمولی مثال دیتے ہیں اور دیکھتے ہیں کہ جب ہم کمپیوٹر میں USB فلیش ڈرائیو ڈالتے ہیں اور سسٹم اس کا پتہ لگاتا ہے تو کیا ہوتا ہے۔

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 اور، بدترین صورت میں، ڈیٹا کھونا۔

تاہم، ہم سب جانتے ہیں کہ بہت سے IoT آلات، نیز راؤٹرز، تھرموسٹیٹ اور کاریں، اب لینکس چلاتے ہیں۔ ان میں سے بہت سے آلات کے پاس کوئی صارف انٹرفیس نہیں ہے، اور انہیں "صاف" سے بند کرنے کا کوئی طریقہ نہیں ہے۔ جب کنٹرول یونٹ کی طاقت ہو تو مردہ بیٹری کے ساتھ کار شروع کرنے کا تصور کریں۔ لینکس مسلسل اوپر اور نیچے کودنا. یہ کیسا ہے کہ سسٹم بغیر کسی لمبے کے بوٹ کرتا ہے۔ fsckآخر انجن کب چلنا شروع ہوتا ہے؟ اور جواب آسان ہے۔ ایمبیڈڈ ڈیوائسز روٹ فائل سسٹم پر انحصار کرتی ہیں۔ صرف پڑھنے کے لیے (مختصرا) ro-rootfs (صرف پڑھنے کے لیے روٹ فائل سسٹم))۔

ro-rootfs بہت سے فوائد پیش کرتے ہیں جو صداقت سے کم واضح ہیں۔ ایک فائدہ یہ ہے کہ میلویئر اسے نہیں لکھ سکتا /usr یا /lib، اگر کوئی لینکس عمل وہاں نہیں لکھ سکتا ہے۔ دوسرا یہ کہ ایک بڑی حد تک غیر تبدیل شدہ فائل سسٹم ریموٹ ڈیوائسز کی فیلڈ سپورٹ کے لیے اہم ہے، کیونکہ سپورٹ اہلکار مقامی سسٹمز پر بھروسہ کرتے ہیں جو کہ فیلڈ سسٹمز سے یکساں ہیں۔ شاید سب سے اہم (بلکہ سب سے زیادہ کپٹی والا) فائدہ یہ ہے کہ ro-rootfs ڈویلپرز کو یہ فیصلہ کرنے پر مجبور کرتا ہے کہ سسٹم کے ڈیزائن کے مرحلے پر کون سی سسٹم آبجیکٹ ناقابل تغیر ہو گی۔ ro-rootfs کے ساتھ کام کرنا عجیب اور تکلیف دہ ہو سکتا ہے، کیونکہ const متغیر اکثر پروگرامنگ زبانوں میں ہوتے ہیں، لیکن ان کے فوائد آسانی سے اضافی اوور ہیڈ کا جواز پیش کرتے ہیں۔

تخلیق rootfs ایمبیڈڈ ڈویلپرز کے لیے صرف پڑھنے کے لیے کچھ اضافی کوشش کی ضرورت ہوتی ہے، اور یہیں سے VFS تصویر میں آتا ہے۔ لینکس کا تقاضا ہے کہ فائلیں اندر ہوں۔ /var قابل تحریر تھے، اور اس کے علاوہ، بہت سی مقبول ایپلی کیشنز جو ایمبیڈڈ سسٹم چلاتی ہیں، کنفیگریشن بنانے کی کوشش کریں گی۔ dot-files в $HOME. ہوم ڈائرکٹری میں کنفیگریشن فائلوں کا ایک حل عام طور پر ان کو پہلے سے تیار کرنا اور ان میں بنانا ہے۔ rootfs. کرنے کے لئے /var ایک ممکنہ نقطہ نظر یہ ہے کہ اسے علیحدہ تحریری تقسیم پر نصب کیا جائے، جبکہ / صرف پڑھنے کے لیے نصب۔ ایک اور مقبول متبادل بائنڈ یا اوورلے ماؤنٹ استعمال کرنا ہے۔

لنک ایبل اور اسٹیک ایبل ماونٹس، کنٹینرز کے ذریعے ان کا استعمال

حکم پر عمل کرنا man mount بائنڈ ایبل اور اوورلی ایبل ماؤنٹس کے بارے میں جاننے کا بہترین طریقہ ہے، جو ڈویلپرز اور سسٹم ایڈمنسٹریٹرز کو ایک راستے میں فائل سسٹم بنانے اور پھر اسے دوسرے راستے میں ایپلی کیشنز کے سامنے لانے کی صلاحیت فراہم کرتا ہے۔ ایمبیڈڈ سسٹمز کے لیے، اس کا مطلب ہے فائلوں کو اسٹور کرنے کی صلاحیت /var صرف پڑھنے کے لیے فلیش ڈرائیو پر، لیکن ایک اوورلے یا لنک ایبل ماؤنٹ پاتھ سے tmpfs в /var لوڈ کرتے وقت، یہ ایپلیکیشنز کو وہاں نوٹ لکھنے کی اجازت دے گا (اسکرال)۔ اگلی بار جب آپ تبدیلیوں کو آن کریں گے۔ /var کھو جائے گا. ایک اوورلے ماؤنٹ کے درمیان اتحاد پیدا ہوتا ہے۔ tmpfs اور بنیادی فائل سسٹم اور آپ کو موجودہ فائلوں میں ظاہری تبدیلیاں کرنے کی اجازت دیتا ہے۔ ro-tootf جبکہ باندھنے کے قابل پہاڑ نئے کو خالی بنا سکتا ہے۔ tmpfs فولڈرز قابل تحریر کے طور پر نظر آتے ہیں۔ ro-rootfs طریقے جبکہ overlayfs یہ صحیح ہے (proper) فائل سسٹم کی قسم، بائنڈ ایبل ماؤنٹ لاگو کیا جاتا ہے۔ VFS نام کی جگہ.

اوورلے اور لنک ایبل ماؤنٹ کی تفصیل کی بنیاد پر، کوئی بھی حیران نہیں ہوتا لینکس کنٹینرز وہ فعال طور پر استعمال کیا جاتا ہے. آئیے دیکھتے ہیں کہ جب ہم استعمال کرتے ہیں تو کیا ہوتا ہے۔ systemd-nspawn ٹول کا استعمال کرتے ہوئے کنٹینر کو چلانے کے لیے mountsnoop سے bcc.

چیلینج۔ system-nspawn چلانے کے دوران کنٹینر شروع کرتا ہے mountsnoop.py.

آئیے دیکھتے ہیں کیا ہوا:

لانچ کریں۔ mountsnoop جبکہ کنٹینر "بوٹنگ" ہوتا ہے اس سے پتہ چلتا ہے کہ کنٹینر کا رن ٹائم ماؤنٹ سے منسلک ہونے پر بہت زیادہ منحصر ہے (صرف لمبی آؤٹ پٹ کا آغاز دکھایا گیا ہے)۔

یہاں systemd-nspawn میں منتخب فائلیں فراہم کرتا ہے۔ procfs и sysfs کنٹینر کو اس کے راستوں کے طور پر میزبانی کریں۔ rootfs. اس کے علاوہ MS_BIND جھنڈا جو بائنڈنگ ماؤنٹ کو سیٹ کرتا ہے، ماؤنٹ پر موجود کچھ دوسرے جھنڈے میزبان اور کنٹینر کے نام کی جگہوں میں ہونے والی تبدیلیوں کے درمیان تعلق کی وضاحت کرتے ہیں۔ مثال کے طور پر، ایک منسلک ماؤنٹ تبدیلیوں کو چھوڑ سکتا ہے۔ /proc и /sys کنٹینر میں، یا کال کے لحاظ سے انہیں چھپائیں۔

حاصل يہ ہوا

لینکس کے اندرونی کاموں کو سمجھنا ایک ناممکن کام کی طرح لگتا ہے، کیونکہ کرنل خود کوڈ کی ایک بڑی مقدار پر مشتمل ہوتا ہے، جس سے سی لائبریریوں میں لینکس کے صارف کی جگہ کی ایپلی کیشنز اور سسٹم کال انٹرفیس کو چھوڑ کر glibc. پیشرفت کرنے کا ایک طریقہ یہ ہے کہ ایک کرنل سب سسٹم کے سورس کوڈ کو پڑھا جائے، جس میں سسٹم کالز اور یوزر اسپیس ہیڈرز کے ساتھ ساتھ مرکزی اندرونی کرنل انٹرفیس جیسے ٹیبل کو سمجھنے پر زور دیا جائے۔ file_operations. فائل آپریشنز "ہر چیز ایک فائل ہے" کا اصول فراہم کرتے ہیں، جس سے ان کا انتظام کرنا خاص طور پر خوشگوار ہوتا ہے۔ اعلی سطحی ڈائرکٹری میں C کرنل سورس فائلز fs/ ورچوئل فائل سسٹم کا نفاذ پیش کرتا ہے، جو کہ ایک ریپر لیئر ہے جو مقبول فائل سسٹمز اور اسٹوریج ڈیوائسز کے درمیان وسیع اور نسبتاً آسان مطابقت فراہم کرتی ہے۔ لینکس نام کی جگہوں کے ذریعے لنکنگ اور اوورلے ماؤنٹنگ VFS کا جادو ہے جو صرف پڑھنے کے لیے کنٹینرز اور روٹ فائل سسٹم کو ممکن بناتا ہے۔ سورس کوڈ، ای بی پی ایف کور ٹول اور اس کے انٹرفیس کی جانچ کے ساتھ مل کر bcc
بنیادی تلاش کو پہلے سے کہیں زیادہ آسان بنانا۔

دوستو، لکھیں، کیا یہ مضمون آپ کے لیے مفید تھا؟ شاید آپ کے پاس کوئی تبصرہ یا تبصرہ ہے؟ اور جو لوگ لینکس ایڈمنسٹریٹر کورس میں دلچسپی رکھتے ہیں ان کو مدعو کیا جاتا ہے۔ کھلے دنجو کہ 18 اپریل کو ہو گا۔

پہلا حصہ.

ماخذ: www.habr.com