ប្រព័ន្ធឯកសារនិម្មិតនៅក្នុងលីនុច៖ ហេតុអ្វីបានជាពួកគេត្រូវការ ហើយតើពួកគេដំណើរការយ៉ាងដូចម្តេច? ផ្នែកទី 2

ជំរាបសួរអ្នកទាំងអស់គ្នា ពួកយើងកំពុងចែករំលែកជាមួយអ្នកនូវផ្នែកទីពីរនៃការបោះពុម្ព “ប្រព័ន្ធឯកសារនិម្មិតនៅក្នុងលីនុច៖ ហេតុអ្វីបានជាពួកគេត្រូវការ ហើយតើពួកគេដំណើរការយ៉ាងដូចម្តេច?” អ្នកអាចអានផ្នែកដំបូង នៅទីនេះ. អនុញ្ញាតឱ្យយើងរំលឹកអ្នកថាស៊េរីនៃការបោះពុម្ពនេះគឺមានពេលវេលាដើម្បីស្របពេលជាមួយនឹងការចាប់ផ្តើមនៃការផ្សាយថ្មីនៅលើវគ្គសិក្សា "អ្នកគ្រប់គ្រងលីនុច"ដែលចាប់ផ្តើមឆាប់ៗនេះ។

របៀបត្រួតពិនិត្យ VFS ដោយប្រើឧបករណ៍ eBPF និង bcc

មធ្យោបាយងាយស្រួលបំផុតដើម្បីយល់ពីរបៀបដែលខឺណែលដំណើរការលើឯកសារ sysfs គឺដើម្បីមើលវានៅក្នុងការអនុវត្ត ហើយវិធីដែលស្រួលបំផុតក្នុងការមើល ARM64 គឺត្រូវប្រើ eBPF ។ eBPF (ខ្លីសម្រាប់តម្រងកញ្ចប់ Berkeley) មានម៉ាស៊ីននិម្មិតដែលកំពុងដំណើរការ ស្នូលដែលអ្នកប្រើប្រាស់ដែលមានសិទ្ធិអាចស្នើសុំ (query) ពីបន្ទាត់ពាក្យបញ្ជា។ ប្រភពខឺណែលប្រាប់អ្នកអាននូវអ្វីដែលខឺណែលអាចធ្វើបាន។ ការដំណើរការឧបករណ៍ eBPF នៅលើប្រព័ន្ធដែលបានផ្ទុកបង្ហាញពីអ្វីដែលខឺណែលកំពុងធ្វើ។

ជាសំណាងល្អ ការចាប់ផ្តើមប្រើប្រាស់ eBPF គឺងាយស្រួលណាស់ដោយមានជំនួយពីឧបករណ៍ ចម្លងជាសម្ងាត់ជូនដែលអាចប្រើបានជាកញ្ចប់ពីការចែកចាយទូទៅ Linux និងឯកសារលម្អិត លោក Bernard Gregg. ឧបករណ៍ bcc គឺជាអក្សរ Python ជាមួយនឹងការបញ្ចូលតូចៗនៃកូដ C ដែលមានន័យថាអ្នកណាម្នាក់ដែលស្គាល់ភាសាទាំងពីរអាចកែប្រែវាបានយ៉ាងងាយស្រួល។ IN bcc/tools មានស្គ្រីប Python ចំនួន 80 ដែលមានន័យថាភាគច្រើនទំនងជាអ្នកអភិវឌ្ឍន៍ ឬអ្នកគ្រប់គ្រងប្រព័ន្ធនឹងអាចជ្រើសរើសអ្វីដែលសមរម្យសម្រាប់ការដោះស្រាយបញ្ហា។
ដើម្បីទទួលបានយ៉ាងហោចណាស់គំនិតស្រពិចស្រពិលនៃការងារដែល VFSs ធ្វើនៅលើប្រព័ន្ធដែលកំពុងដំណើរការ សូមសាកល្បង vfscount ឬ vfsstat. នេះនឹងបង្ហាញ, ឧបមាថា, ការហៅទូរស័ព្ទរាប់សិប vfs_open() ហើយ "មិត្តរបស់គាត់" កើតឡើងជារៀងរាល់វិនាទី។

vfsstat.py គឺជាស្គ្រីប Python ជាមួយនឹងការបញ្ចូលកូដ C ដែលគ្រាន់តែរាប់ការហៅមុខងារ VFS ។

ចូរយើងផ្តល់ឧទាហរណ៍ដ៏តូចមួយបន្ថែមទៀត ហើយមើលថាតើមានអ្វីកើតឡើងនៅពេលដែលយើងបញ្ចូល USB flash drive ទៅក្នុងកុំព្យូទ័រ ហើយប្រព័ន្ធរកឃើញវា។

ដោយប្រើ eBPF អ្នកអាចឃើញអ្វីដែលកំពុងកើតឡើងនៅក្នុង /sysនៅពេលបញ្ចូល USB flash drive ។ ឧទាហរណ៍សាមញ្ញ និងស្មុគស្មាញត្រូវបានបង្ហាញនៅទីនេះ។

នៅក្នុងឧទាហរណ៍ដែលបានបង្ហាញខាងលើ។ bcc ឧបករណ៍ trace.py បោះពុម្ពសារនៅពេលដែលពាក្យបញ្ជាត្រូវបានដំណើរការ sysfs_create_files(). យើងឃើញនោះ។ sysfs_create_files() ត្រូវបានបើកដំណើរការដោយប្រើ kworker ស្ទ្រីមឆ្លើយតបទៅនឹងការពិតដែលថាដ្រាយវ៍ពន្លឺត្រូវបានបញ្ចូលប៉ុន្តែតើឯកសារអ្វីត្រូវបានបង្កើត? ឧទាហរណ៍ទីពីរបង្ហាញពីអំណាចនៃ eBPF ។ នៅទីនេះ trace.py បោះពុម្ពខឺណែល backtrace (-K ជម្រើស) និងឈ្មោះឯកសារដែលត្រូវបានបង្កើត sysfs_create_files(). ការបញ្ចូលសេចក្តីថ្លែងការណ៍តែមួយគឺជាកូដ C ដែលរួមបញ្ចូលខ្សែអក្សរទម្រង់ដែលអាចស្គាល់បានយ៉ាងងាយស្រួលដែលផ្តល់ដោយស្គ្រីប Python ដែលដំណើរការ LLVM កម្មវិធីចងក្រងតាមពេលវេលា. វាចងក្រងបន្ទាត់នេះ ហើយប្រតិបត្តិវានៅក្នុងម៉ាស៊ីននិម្មិតនៅខាងក្នុងខឺណែល។ ហត្ថលេខាមុខងារពេញលេញ sysfs_create_files () ត្រូវតែផលិតឡើងវិញនៅក្នុងពាក្យបញ្ជាទីពីរ ដូច្នេះខ្សែទម្រង់អាចយោងទៅលើប៉ារ៉ាម៉ែត្រមួយក្នុងចំណោមប៉ារ៉ាម៉ែត្រ។ កំហុសនៅក្នុងផ្នែកនៃកូដ C នេះបណ្តាលឱ្យមានកំហុសដែលអាចស្គាល់បានពី C compiler ។ ឧទាហរណ៍ ប្រសិនបើប៉ារ៉ាម៉ែត្រ -l ត្រូវបានលុបចោល អ្នកនឹងឃើញ "បរាជ័យក្នុងការចងក្រងអត្ថបទ BPF" ។ អ្នកអភិវឌ្ឍន៍ដែលស្គាល់ C និង Python នឹងស្វែងរកឧបករណ៍ bcc ងាយស្រួលពង្រីក និងផ្លាស់ប្តូរ។

នៅពេលបញ្ចូល USB drive នោះ kernel backtrace នឹងបង្ហាញថា PID 7711 គឺជាខ្សែស្រឡាយ kworkerដែលបានបង្កើតឯកសារ «events» в sysfs. អាស្រ័យហេតុនេះ ការហៅទូរស័ព្ទពី sysfs_remove_files() នឹងបង្ហាញថាការដកដ្រាយចេញជាលទ្ធផលដែលឯកសារត្រូវបានលុប eventsដែលត្រូវនឹងគំនិតទូទៅនៃការរាប់យោង។ ទន្ទឹមនឹងនេះការមើល sysfs_create_link () ជាមួយ eBPF ពេលបញ្ចូល USB drive នឹងបង្ហាញថាយ៉ាងហោចណាស់ 48 តំណភ្ជាប់និមិត្តសញ្ញាត្រូវបានបង្កើតឡើង។

ដូច្នេះតើអ្វីជាចំណុចនៃឯកសារព្រឹត្តិការណ៍? ការប្រើប្រាស់ cscope សម្រាប់ការស្វែងរក __device_add_disk()បង្ហាញពីអ្វីដែលវាបណ្តាលឱ្យ disk_add_events (), និង "media_change", ឬ "eject_request" អាចត្រូវបានកត់ត្រានៅក្នុងឯកសារព្រឹត្តិការណ៍។ នៅទីនេះ ស្រទាប់ប្លុកខឺណែលជូនដំណឹងដល់លំហអ្នកប្រើប្រាស់ថា "ថាស" បានលេចចេញ និងច្រានចេញ។ ចំណាំថាតើវិធីសាស្រ្តស្រាវជ្រាវនេះផ្តល់ព័ត៌មានយ៉ាងណាដោយការបញ្ចូល USB drive បើប្រៀបធៀបទៅនឹងការព្យាយាមស្វែងយល់ពីរបៀបដែលអ្វីៗដំណើរការសុទ្ធសាធពីប្រភព។

ប្រព័ន្ធឯកសារ root បានតែអាន បើកឧបករណ៍ដែលបានបង្កប់

ជាការពិតណាស់ គ្មាននរណាម្នាក់បិទម៉ាស៊ីនមេ ឬកុំព្យូទ័ររបស់ពួកគេដោយទាញដោតចេញពីរន្ធនោះទេ។ តែ​ហេតុអ្វី? នេះគឺដោយសារតែប្រព័ន្ធឯកសារដែលបានម៉ោននៅលើឧបករណ៍ផ្ទុកទិន្នន័យអាចមានការសរសេរយឺត ហើយរចនាសម្ព័ន្ធទិន្នន័យដែលកត់ត្រាស្ថានភាពរបស់ពួកគេអាចនឹងមិនត្រូវបានធ្វើសមកាលកម្មជាមួយនឹងការសរសេរទៅកន្លែងផ្ទុក។ នៅពេលវាកើតឡើង ម្ចាស់ប្រព័ន្ធត្រូវរង់ចាំរហូតដល់ការចាប់ផ្ដើមបន្ទាប់ដើម្បីបើកដំណើរការឧបករណ៍ប្រើប្រាស់។ fsck filesystem-recovery ហើយក្នុងករណីដ៏អាក្រក់បំផុត ការបាត់បង់ទិន្នន័យ។

ទោះជាយ៉ាងណាក៏ដោយ យើងទាំងអស់គ្នាដឹងថាឧបករណ៍ IoT ជាច្រើន ក៏ដូចជារ៉ោតទ័រ ឧបករណ៍កម្តៅ និងរថយន្ត ឥឡូវនេះដំណើរការលីនុច។ ឧបករណ៍ទាំងនេះជាច្រើនមានចំណុចប្រទាក់អ្នកប្រើតិចតួច ឬគ្មាន ហើយមិនមានវិធីដើម្បីបិទពួកវា "យ៉ាងស្អាត" នោះទេ។ ស្រមៃថាចាប់ផ្តើមឡានដោយថ្មងាប់នៅពេលដែលថាមពលទៅអង្គភាពបញ្ជា Linux លោតចុះឡើងឥតឈប់ឈរ។ តើ​ប្រព័ន្ធ​ដំណើរការ​ដោយ​មិន​ចាំ​យូរ​ដោយ​របៀប​ណា? fsckតើនៅពេលណាដែលម៉ាស៊ីនចាប់ផ្តើមដំណើរការ? ហើយចម្លើយគឺសាមញ្ញ។ ឧបករណ៍ដែលបានបង្កប់ពឹងផ្អែកលើប្រព័ន្ធឯកសារឫស សម្រាប់តែការអាន (អក្សរសង្ខេប ro-rootfs (ប្រព័ន្ធឯកសារឫសបានតែអាន)) ។

ro-rootfs ផ្តល់អត្ថប្រយោជន៍ជាច្រើនដែលមិនច្បាស់ជាងភាពពិតប្រាកដ។ អត្ថប្រយោជន៍មួយគឺថាមេរោគមិនអាចសរសេរទៅ /usr ឬ /libប្រសិនបើគ្មានដំណើរការលីនុចអាចសរសេរនៅទីនោះ។ មួយទៀតគឺថាប្រព័ន្ធឯកសារដែលមិនអាចផ្លាស់ប្តូរបានគឺមានសារៈសំខាន់សម្រាប់ការគាំទ្រផ្នែកឧបករណ៍ពីចម្ងាយ ចាប់តាំងពីបុគ្គលិកជំនួយពឹងផ្អែកលើប្រព័ន្ធមូលដ្ឋានដែលមានលក្ខណៈដូចគ្នាបេះបិទទៅនឹងប្រព័ន្ធវាល។ ប្រហែលជាអត្ថប្រយោជន៍ដ៏សំខាន់បំផុត (ប៉ុន្តែក៏អាក្រក់បំផុតផងដែរ) គឺថា ro-rootfs បង្ខំអ្នកអភិវឌ្ឍន៍ឱ្យសម្រេចចិត្តថាតើវត្ថុប្រព័ន្ធណាមួយនឹងមិនអាចផ្លាស់ប្តូរបាននៅដំណាក់កាលរចនានៃប្រព័ន្ធ។ ការធ្វើការជាមួយ ro-rootfs អាចជារឿងឆ្គង និងឈឺចាប់ ដោយសារអថេរ const ច្រើនតែមាននៅក្នុងភាសាសរសេរកម្មវិធី ប៉ុន្តែអត្ថប្រយោជន៍របស់វាងាយស្រួលបង្ហាញអំពីភាពត្រឹមត្រូវបន្ថែម។

ការបង្កើត rootfs ការអានបានតែទាមទារការខិតខំប្រឹងប្រែងបន្ថែមមួយចំនួនសម្រាប់អ្នកអភិវឌ្ឍន៍ដែលបានបង្កប់ ហើយនេះគឺជាកន្លែងដែល VFS ចូលមកក្នុងរូបភាព។ លីនុច ទាមទារឱ្យឯកសារនៅក្នុង /var អាចសរសេរបាន ហើយលើសពីនេះទៀត កម្មវិធីពេញនិយមជាច្រើនដែលដំណើរការប្រព័ន្ធបង្កប់នឹងព្យាយាមបង្កើតការកំណត់ dot-files в $HOME. ដំណោះ​ស្រាយ​មួយ​សម្រាប់​ឯកសារ​កំណត់​រចនាសម្ព័ន្ធ​ក្នុង​ថត​ផ្ទះ​ជា​ធម្មតា​គឺ​ត្រូវ​បង្កើត​ជា​មុន​ និង​បង្កើត​វា​ចូល​ក្នុង​ rootfs។ សម្រាប់ /var វិធីសាស្រ្តមួយដែលអាចធ្វើទៅបានគឺត្រូវម៉ោនវានៅលើភាគថាសដែលអាចសរសេរបានដាច់ដោយឡែក / បានដំឡើងសម្រាប់តែអាន។ ជម្រើសដ៏ពេញនិយមមួយទៀតគឺប្រើការចង ឬដាក់ជាន់លើ។

ម៉ោនដែលអាចភ្ជាប់បាន និងអាចជង់បាន ការប្រើប្រាស់របស់ពួកគេដោយធុង

ការប្រតិបត្តិពាក្យបញ្ជា man mount គឺជាវិធីដ៏ល្អបំផុតដើម្បីសិក្សាអំពី bindable and overlayable mounts ដែលផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍ និងអ្នកគ្រប់គ្រងប្រព័ន្ធនូវសមត្ថភាពក្នុងការបង្កើតប្រព័ន្ធឯកសារមួយក្នុងផ្លូវមួយ ហើយបន្ទាប់មកលាតត្រដាងវាទៅកម្មវិធីក្នុងមួយផ្សេងទៀត។ សម្រាប់ប្រព័ន្ធបង្កប់ នេះមានន័យថាសមត្ថភាពក្នុងការរក្សាទុកឯកសារនៅក្នុង /var នៅលើដ្រាយវ៍ពន្លឺបានតែអាន ប៉ុន្តែជាផ្លូវភ្ជាប់ ឬផ្លូវម៉ោនដែលអាចភ្ជាប់បានពី tmpfs в /var នៅពេលផ្ទុក វានឹងអនុញ្ញាតឱ្យកម្មវិធីសរសេរកំណត់ចំណាំនៅទីនោះ (អូសទាញ)។ លើកក្រោយដែលអ្នកបើកការផ្លាស់ប្តូរទៅ /var នឹងត្រូវបាត់បង់។ ម៉ោនត្រួតលើគ្នាបង្កើតសហជីពរវាង tmpfs និងប្រព័ន្ធឯកសារមូលដ្ឋាន និងអនុញ្ញាតឱ្យអ្នកធ្វើការផ្លាស់ប្តូរជាក់ស្តែងចំពោះឯកសារដែលមានស្រាប់នៅក្នុង ro-tootf ចំណែក​ឯ​ម៉ោន​ដែល​អាច​ចង​បាន​អាច​ធ្វើ​ឱ្យ​ថ្មី​ទទេ tmpfs ថតដែលអាចមើលឃើញថាអាចសរសេរបាននៅក្នុង ro-rootfs វិធី។ ខណៈពេលដែល overlayfs នេះជាការត្រឹមត្រូវ (proper) ប្រភេទប្រព័ន្ធឯកសារ ម៉ោនដែលអាចចងបានត្រូវបានអនុវត្តនៅក្នុង ចន្លោះឈ្មោះ VFS.

ដោយផ្អែកលើការពិពណ៌នានៃការត្រួតគ្នានិងម៉ោនដែលអាចភ្ជាប់បានគ្មាននរណាម្នាក់ភ្ញាក់ផ្អើលនោះទេ។ ធុងផ្ទុកលីនុច ពួកវាត្រូវបានប្រើយ៉ាងសកម្ម។ តោះមើលថាតើមានអ្វីកើតឡើងនៅពេលយើងប្រើ systemd-spawn ដើម្បីដំណើរការកុងតឺន័រដោយប្រើឧបករណ៍ mountsnoop ពី bcc.

បញ្ហាប្រឈម system-nspawn ចាប់ផ្តើមធុងខណៈពេលកំពុងដំណើរការ mountsnoop.py.

តោះមើលថាមានអ្វីកើតឡើង៖

បើកដំណើរការ mountsnoop ខណៈពេលដែលកុងតឺន័រកំពុង "ចាប់ផ្ដើម" បង្ហាញថារយៈពេលដំណើរការរបស់កុងតឺន័រគឺពឹងផ្អែកខ្លាំងលើម៉ោនដែលត្រូវបានភ្ជាប់ (មានតែការចាប់ផ្តើមនៃទិន្នផលវែងប៉ុណ្ណោះត្រូវបានបង្ហាញ) ។

វាគឺជាការ systemd-nspawn ផ្តល់ឯកសារដែលបានជ្រើសរើសនៅក្នុង procfs и sysfs host ទៅកាន់កុងតឺន័រជាផ្លូវទៅកាន់វា។ rootfs... ក្រៅពី MS_BIND ទង់ដែលកំណត់ការដំឡើង binding mount ទង់មួយចំនួនផ្សេងទៀតនៅលើ mount កំណត់ទំនាក់ទំនងរវាងការផ្លាស់ប្តូរទៅ host និង container namespaces ។ ឧទាហរណ៍ ម៉ោនថ៍ដែលភ្ជាប់អាចរំលងការផ្លាស់ប្តូរទៅ /proc и /sys ចូលទៅក្នុងកុងតឺន័រ ឬលាក់ពួកវាអាស្រ័យលើការហៅទូរសព្ទ។

សេចក្តីសន្និដ្ឋាន

ការយល់ដឹងពីការងារខាងក្នុងរបស់លីនុចអាចហាក់ដូចជាកិច្ចការដែលមិនអាចទៅរួច ព្រោះខឺណែលខ្លួនវាផ្ទុកនូវកូដយ៉ាងច្រើន ដោយបន្សល់ទុកនូវកម្មវិធីចន្លោះអ្នកប្រើប្រាស់លីនុច និងចំណុចប្រទាក់ហៅប្រព័ន្ធនៅក្នុងបណ្ណាល័យ C ដូចជា glibc. វិធីមួយដើម្បីធ្វើឱ្យមានវឌ្ឍនភាពគឺការអានកូដប្រភពនៃប្រព័ន្ធរងខឺណែលមួយ ដោយសង្កត់ធ្ងន់លើការយល់ដឹងអំពីការហៅប្រព័ន្ធ និងបឋមកថាទំហំអ្នកប្រើប្រាស់ ក៏ដូចជាចំណុចប្រទាក់ខឺណែលខាងក្នុងសំខាន់ៗ ដូចជាតារាង។ file_operations. ប្រតិបត្តិការឯកសារផ្តល់នូវគោលការណ៍ "អ្វីគ្រប់យ៉ាងគឺជាឯកសារ" ដែលធ្វើឱ្យពួកគេរីករាយជាពិសេសក្នុងការគ្រប់គ្រង។ ឯកសារប្រភពខឺណែល C នៅក្នុងថតកម្រិតកំពូល fs/ បង្ហាញពីការអនុវត្តប្រព័ន្ធឯកសារនិម្មិត ដែលជាស្រទាប់រុំដែលផ្តល់នូវភាពឆបគ្នាយ៉ាងទូលំទូលាយ និងសាមញ្ញរវាងប្រព័ន្ធឯកសារពេញនិយម និងឧបករណ៍ផ្ទុក។ ការភ្ជាប់ និងការភ្ជាប់ត្រួតលើគ្នាតាមរយៈ namespaces លីនុច គឺជាវេទមន្តនៃ VFS ដែលធ្វើឱ្យការបង្កើតធុងសម្រាប់តែអាន និងប្រព័ន្ធឯកសារឫសអាចធ្វើទៅបាន។ រួមបញ្ចូលគ្នាជាមួយនឹងការពិនិត្យមើលកូដប្រភព ឧបករណ៍ស្នូល eBPF និងចំណុចប្រទាក់របស់វា។ bcc
ធ្វើឱ្យការរុករកស្នូលមានភាពងាយស្រួលជាងពេលណាទាំងអស់។

មិត្តអ្នកសរសេរ តើអត្ថបទនេះមានប្រយោជន៍សម្រាប់អ្នកទេ? ប្រហែល​ជា​អ្នក​មាន​យោបល់​ឬ​ការ​កត់​សម្គាល់? ហើយអ្នកដែលចាប់អារម្មណ៍លើវគ្គសិក្សា Linux Administrator ត្រូវបានអញ្ជើញឱ្យចូលរួម ថ្ងៃបើកដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃទី ១៨ ខែមេសា។

ផ្នែកដំបូង។

ប្រភព: www.habr.com