لينڪس ۾ ورچوئل فائل سسٽم: اهي ڇو گهربل آهن ۽ اهي ڪيئن ڪم ڪن ٿا؟ حصو 2

سڀني کي هيلو، اسان توهان سان شيئر ڪري رهيا آهيون پبليڪيشن جو ٻيو حصو ”ورچوئل فائل سسٽم لينڪس ۾: انهن جي ضرورت ڇو آهي ۽ اهي ڪيئن ڪم ڪن ٿا؟ توهان پڙهي سگهو ٿا پهريون حصو هتي. اچو ته توهان کي ياد ڏياريون ته اشاعتن جو هي سلسلو ڪورس تي هڪ نئين اسٽريم جي شروعات سان گڏ آهي "لينڪس ايڊمنسٽريٽر"، جيڪو تمام جلد شروع ٿئي ٿو.

اي بي پي ايف ۽ بي سي سي اوزار استعمال ڪندي VFS مانيٽر ڪيئن ڪجي

سمجھڻ جو آسان طريقو آھي ڪھڙي ريت ڪنيل فائلن تي ڪم ڪندو آھي sysfs ان کي عملي طور تي ڏسڻو آهي، ۽ ARM64 ڏسڻ جو آسان طريقو آهي eBPF استعمال ڪرڻ. eBPF (برڪلي پيڪٽ فلٽر لاءِ مختصر) هڪ ورچوئل مشين تي مشتمل آهي بنيادي، جنهن کي مراعات يافته صارف درخواست ڪري سگھن ٿا (query) ڪمانڊ لائن مان. ڪنيل جا ذريعا پڙهندڙ کي ٻڌائين ٿا ته ڪنيل ڇا ڪري سگهي ٿو؛ اي بي پي ايف ٽولز کي لوڊ ٿيل سسٽم تي هلائڻ ڏيکاري ٿو ته ڪنيل اصل ۾ ڇا ڪري رهيو آهي.

لينڪس ۾ ورچوئل فائل سسٽم: اهي ڇو گهربل آهن ۽ اهي ڪيئن ڪم ڪن ٿا؟ حصو 2

خوش قسمت، اي بي پي ايف استعمال ڪرڻ شروع ڪرڻ بلڪل آسان آهي اوزار جي مدد سان بي سي سي، جيڪي عام تقسيم کان پيڪيجز جي طور تي دستياب آهن لينڪس ۽ تفصيل سان دستاويز ڪيو برنارڊ گريگ. اوزار bcc Python اسڪرپٽ آهن سي ڪوڊ جي ننڍڙن داخلائن سان، جنهن جو مطلب آهي ته ٻنهي ٻولين کان واقف ماڻهو انهن کي آساني سان تبديل ڪري سگهي ٿو. IN bcc/tools هتي 80 پٿون اسڪرپٽ آهن، جنهن جو مطلب آهي ته گهڻو ڪري هڪ ڊولپر يا سسٽم ايڊمنسٽريٽر مسئلو حل ڪرڻ لاءِ مناسب ڪجهه چونڊڻ جي قابل هوندو.
گهٽ ۾ گهٽ هڪ سطحي خيال حاصل ڪرڻ لاءِ ته وي ايف ايس هلندڙ سسٽم تي ڪهڙو ڪم ڪن ٿا، ڪوشش ڪريو vfscount يا vfsstat. اهو ڏيکاريندو، اچو ته چوندا آهن، ته درجنين ڪالون vfs_open() ۽ "هن جا دوست" لفظي طور تي هر سيڪنڊ ۾ ٿين ٿا.

لينڪس ۾ ورچوئل فائل سسٽم: اهي ڇو گهربل آهن ۽ اهي ڪيئن ڪم ڪن ٿا؟ حصو 2

vfsstat.py هڪ پٿون اسڪرپٽ آهي سي ڪوڊ داخل ڪرڻ سان جيڪو صرف VFS فنڪشن ڪالن کي شمار ڪري ٿو.

اچو ته هڪ وڌيڪ معمولي مثال ڏيون ۽ ڏسو ته ڇا ٿيندو جڏهن اسان ڪمپيوٽر ۾ USB فليش ڊرائيو داخل ڪيو ۽ سسٽم ان کي ڳولي ٿو.

لينڪس ۾ ورچوئل فائل سسٽم: اهي ڇو گهربل آهن ۽ اهي ڪيئن ڪم ڪن ٿا؟ حصو 2

اي بي پي ايف استعمال ڪندي توهان ڏسي سگهو ٿا ته ڇا ٿي رهيو آهي /sysجڏهن هڪ USB فليش ڊرائيو داخل ڪيو ويو آهي. هڪ سادي ۽ پيچيده مثال هتي ڏيکاريل آهي.

مٿي ڏيکاريل مثال ۾، bcc اوزار trace.py هڪ پيغام پرنٽ ڪندو آهي جڏهن حڪم هلندي آهي sysfs_create_files(). اسان اهو ڏسون ٿا sysfs_create_files() استعمال ڪندي شروع ڪيو ويو kworker stream ان حقيقت جي جواب ۾ ته فليش ڊرائيو داخل ڪيو ويو، پر ڪهڙي فائل ٺاهي وئي؟ ٻيو مثال ڏيکاري ٿو اي بي پي ايف جي طاقت. هتي trace.py پرنٽ ڪري ٿو هڪ ڪنيل پٺاڻ (-K آپشن) ۽ فائل جو نالو جيڪو ٺاهيو ويو sysfs_create_files(). اڪيلو بيان داخل ڪرڻ C ڪوڊ آهي جنهن ۾ شامل آهي آساني سان سڃاڻڻ واري فارميٽ اسٽرنگ جيڪا Python اسڪرپٽ پاران مهيا ڪيل آهي جيڪا LLVM هلائي ٿي. صرف وقت ۾ گڏ ڪرڻ وارو. اهو هن لڪير کي گڏ ڪري ٿو ۽ ان کي انجام ڏئي ٿو هڪ ورچوئل مشين ۾ ڪرنل اندر. مڪمل فنڪشن دستخط sysfs_create_files () ٻئي ڪمانڊ ۾ ٻيهر پيش ڪيو وڃي ته جيئن فارميٽ اسٽرنگ ھڪڙي پيٽرولر جو حوالو ڏئي سگھي. C ڪوڊ جي هن ٽڪرا ۾ غلطيون C compiler مان سڃاڻڻ واري غلطين جي نتيجي ۾. مثال طور، جيڪڏهن -l پيٽرولر کي ختم ڪيو ويو آهي، توهان ڏسندا "BPF متن گڏ ڪرڻ ۾ ناڪام." ڊولپر جيڪي سي ۽ پٿون کان واقف آهن اهي اوزار ڳوليندا bcc وڌائڻ ۽ تبديل ڪرڻ آسان.

جڏهن يو ايس بي ڊرائيو داخل ڪيو ويندو، ڪني جي پٺڀرائي ڏيکاريندي ته 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 ڊوائيسز، گڏوگڏ روٽر، thermostats ۽ ڪارون، هاڻي لينڪس هلائيندا آهن. انهن مان گھڻا ڊوائيس ڪجھ به نه آھن ڪو صارف انٽرفيس، ۽ انھن کي "صاف" بند ڪرڻ جو ڪو طريقو نه آھي. تصور ڪريو هڪ ڪار شروع ڪرڻ مئل بيٽري سان جڏهن ڪنٽرول يونٽ جي طاقت آهي لينڪس مسلسل مٿي ۽ هيٺ ٽپو ڏيڻ. اهو ڪيئن آهي ته سسٽم بوٽن بغير ڊگهي fsckانجڻ آخر ڪڏهن هلڻ شروع ٿيندي؟ ۽ جواب سادو آهي. ايمبيڊڊ ڊوائيسز روٽ فائل سسٽم تي ڀروسو ڪن ٿا صرف پڙهڻ لاء (مختصر ro-rootfs (صرف پڙهڻ لاءِ روٽ فائل سسٽم)).

ro-rootfs ڪيترائي فائدا پيش ڪن ٿا جيڪي صداقت کان گهٽ واضح آهن. ھڪڙو فائدو اھو آھي ته مالويئر لکي نٿو سگھي /usr يا /lib، جيڪڏهن ڪو به لينڪس پروسيس اتي لکي نٿو سگهي. ٻيو اهو آهي ته هڪ وڏي حد تائين ناقابل قابل فائل سسٽم ريموٽ ڊوائيسز جي فيلڊ سپورٽ لاء اهم آهي، ڇو ته سپورٽ اهلڪار مقامي سسٽم تي ڀروسو ڪندا آهن جيڪي فيلڊ سسٽم جي نالي سان هڪجهڙائي رکن ٿيون. شايد سڀ کان وڌيڪ اهم (بلڪه سڀ کان وڌيڪ خطرناڪ) فائدو اهو آهي ته ro-rootfs ڊولپرز کي اهو فيصلو ڪرڻ تي مجبور ڪري ٿو ته سسٽم جي ڊيزائن اسٽيج تي ڪهڙيون شيون غير تبديل ٿي وينديون. ro-rootfs سان ڪم ڪرڻ مشڪل ۽ ڏکوئيندڙ ٿي سگهي ٿو، ڇاڪاڻ ته const variables اڪثر ڪري پروگرامنگ ٻولين ۾ هوندا آهن، پر انهن جا فائدا آسانيءَ سان اضافي اوور هيڊ کي ثابت ڪن ٿا.

خلق rootfs صرف پڙهڻ جي ضرورت آهي ايمبيڊ ٿيل ڊولپرز لاءِ ڪجهه اضافي ڪوششون، ۽ اهو آهي جتي VFS تصوير ۾ اچي ٿو. لينڪس جي ضرورت آهي ته فائلون اندر هجن /var لکڻ جي قابل هئا، ۽ ان کان علاوه، ڪيتريون ئي مشهور ايپليڪيشنون جيڪي ايمبيڊڊ سسٽم هلائينديون آهن، ترتيب ڏيڻ جي ڪوشش ڪنديون dot-files в $HOME. گهر ڊاريڪٽري ۾ ترتيب ڏيڻ واري فائلن لاء هڪ حل عام طور تي اڳ ۾ پيدا ڪرڻ ۽ ان ۾ تعمير ڪرڻ آهي rootfs. لاء /var هڪ ممڪن طريقو اهو آهي ته ان کي الڳ لکڻ واري ورهاڱي تي نصب ڪيو وڃي، جڏهن ته / صرف پڙهڻ لاء نصب ٿيل. ٻيو مشهور متبادل بائنڊ يا اوورلي مائونٽ استعمال ڪرڻ آهي.

ڳنڍڻ لائق ۽ اسٽيڪبل مائونٽ، انهن جو استعمال ڪنٽينر ذريعي

حڪم هلائڻ man mount پابند ۽ اوورليبل مائونٽ جي باري ۾ سکڻ جو بهترين طريقو آهي، جيڪو ڊولپرز ۽ سسٽم ايڊمنسٽريٽرن کي هڪ رستي ۾ فائيل سسٽم ٺاهڻ جي صلاحيت ڏئي ٿو ۽ پوءِ ان کي ٻئي رستي ۾ ايپليڪيشنن ڏانهن بي نقاب ڪري ٿو. ايمبيڊڊ سسٽم لاءِ، ان جو مطلب آهي فائلن کي ذخيرو ڪرڻ جي صلاحيت /var صرف پڙهڻ لاءِ فليش ڊرائيو تي، پر هڪ اوورلي يا ڳنڍڻ لائق مائونٽ واٽ تان tmpfs в /var جڏهن لوڊ ٿي رهيو آهي، اهو ايپليڪيشنن کي اتي نوٽس لکڻ جي اجازت ڏيندو (اسڪرول). ايندڙ ڀيري توھان چالو ڪيو تبديلين کي /var گم ٿي ويندو. هڪ اوورلي جبل وچ ۾ هڪ اتحاد ٺاهي ٿو tmpfs ۽ هيٺيون فائل سسٽم ۽ توهان کي موجوده فائلن ۾ ظاهري تبديليون ڪرڻ جي اجازت ڏئي ٿي ro-tootf جڏهن ته هڪ پابند جبل نوان خالي ڪري سگهي ٿو tmpfs فولڊر نظر اچن ٿا جيئن لکڻ جي قابل ro-rootfs طريقا. جڏهن ته overlayfs هي صحيح آهي (proper) فائل سسٽم جو قسم، پابند ٿيل جبل ۾ لاڳو ٿئي ٿو VFS نالي جي جڳھ.

اوورلي ۽ ڳنڍڻ واري جبل جي وضاحت جي بنياد تي، ڪو به حيران ناهي ته لينڪس ڪنٽينرز اهي فعال طور تي استعمال ڪيا ويا آهن. اچو ته ڏسو ته ڇا ٿيندو جڏهن اسان استعمال ڪندا آهيون سسٽمڊ-نون اسپان اوزار استعمال ڪندي ڪنٽينر کي هلائڻ لاء mountsnoop от bcc.

چيلنج system-nspawn هلائڻ دوران ڪنٽينر شروع ٿئي ٿو mountsnoop.py.

اچو ته ڏسون ڇا ٿيو:

لانچ ڪريو mountsnoop جڏهن ته ڪنٽينر آهي ”بوٽنگ“ ڏيکاري ٿو ته ڪنٽينر جو رن ٽائم تمام گهڻو منحصر آهي جبل جي ڳنڍيل هجڻ تي (صرف ڊگهي اوٽ جي شروعات ڏيکاريل آهي).

اهو آهي systemd-nspawn ۾ چونڊيل فائلون مهيا ڪري ٿي procfs и sysfs ميزبان کي ڪنٽينر ان جي رستا طور rootfs... ان کان علاوه MS_BIND جھنڊو جيڪو بائنڊنگ ماؤنٽ کي سيٽ ڪري ٿو، ماؤنٽ تي ڪجھ ٻيا جھنڊا ھوسٽ ۽ ڪنٽينر جي نالن جي جڳھ ۾ تبديلين جي وچ ۾ تعلق بيان ڪن ٿا. مثال طور، هڪ ڳنڍيل جبل يا ته تبديلين کي ڇڏي سگهي ٿو /proc и /sys ڪنٽينر ۾، يا انهن کي لڪايو ڪال تي منحصر ڪري ٿو.

ٿڪل

لينڪس جي اندروني ڪم کي سمجهڻ هڪ ناممڪن ڪم وانگر لڳي سگهي ٿو، ڇاڪاڻ ته ڪرنل پاڻ ۾ ڪوڊ جي هڪ وڏي مقدار تي مشتمل آهي، لينڪس يوزر اسپيس ايپليڪيشنن ۽ سسٽم ڪال انٽرفيس کي ڇڏي C لائبريرين ۾ جهڙوڪ. glibc. ترقي ڪرڻ جو هڪ طريقو اهو آهي ته هڪ ڪنيل سب سسٽم جو سورس ڪوڊ پڙهو، جنهن ۾ سسٽم ڪالز ۽ يوزر اسپيس هيڊرز کي سمجهڻ تي زور ڏنو وڃي، انهي سان گڏ مکيه اندروني ڪنيل انٽرفيس، جهڙوڪ ٽيبل file_operations. فائل آپريشنز مهيا ڪن ٿا "هر شي هڪ فائل آهي" اصول، انهن کي منظم ڪرڻ لاء خاص طور تي خوشگوار بڻائي ٿو. C kernel سورس فائلون مٿين سطح جي ڊاريڪٽري ۾ fs/ ورچوئل فائل سسٽم جو هڪ نفاذ پيش ڪري ٿو، جيڪي هڪ لفافي پرت آهن جيڪي مشهور فائل سسٽم ۽ اسٽوريج ڊوائيسز جي وچ ۾ وسيع ۽ نسبتا سادي مطابقت مهيا ڪن ٿيون. لينڪس نالي اسپيس ذريعي ڳنڍڻ ۽ اوورلي لڳائڻ VFS جو جادو آهي جيڪو صرف پڙهڻ لاءِ ڪنٽينر ۽ روٽ فائل سسٽم ٺاهڻ کي ممڪن بڻائي ٿو. ماخذ ڪوڊ جي امتحان سان گڏ، eBPF بنيادي اوزار ۽ ان جي انٽرفيس bcc
بنيادي ڳولا کي هميشه کان وڌيڪ آسان بڻائي ٿو.

دوستو، لکو، ڇا هي مضمون اوهان لاءِ ڪارائتو هو؟ شايد توهان وٽ ڪي رايا يا تبصرا آهن؟ ۽ جيڪي لينڪس ايڊمنسٽريٽر ڪورس ۾ دلچسپي رکن ٿا انهن کي دعوت ڏني وئي آهي کليل ڏينهن، جيڪو 18 اپريل تي ٿيندو.

پهريون حصو.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو