Ողջույն բոլորին, մենք ձեզ հետ կիսվում ենք «Վիրտուալ ֆայլային համակարգեր Linux-ում. ինչու են դրանք անհրաժեշտ և ինչպես են նրանք աշխատում» հրապարակման երկրորդ մասով։ Կարող եք կարդալ առաջին մասը
Ինչպես վերահսկել VFS-ը՝ օգտագործելով eBPF և bcc գործիքներ
Ամենահեշտ ձևը հասկանալու, թե ինչպես է միջուկը գործում ֆայլերի վրա sysfs
դա գործնականում տեսնելն է, իսկ ARM64 դիտելու ամենահեշտ ձևը eBPF-ն օգտագործելն է: eBPF (կրճատ՝ Berkeley Packet Filter) բաղկացած է վիրտուալ մեքենայից, որն աշխատում է query
) հրամանի տողից: Միջուկի աղբյուրները ընթերցողին ասում են, թե ինչ կարող է անել միջուկը. բեռնված համակարգի վրա eBPF գործիքների գործարկումը ցույց է տալիս, թե իրականում ինչ է անում միջուկը:
Բարեբախտաբար, eBPF-ի օգտագործումը սկսելը բավականին հեշտ է գործիքների օգնությամբ bcc
Python-ի սկրիպտներ են C կոդի փոքր ներդիրներով, ինչը նշանակում է, որ երկու լեզուներին ծանոթ յուրաքանչյուր ոք կարող է հեշտությամբ փոփոխել դրանք: IN bcc/tools
Կան Python-ի 80 սկրիպտներ, ինչը նշանակում է, որ ամենայն հավանականությամբ ծրագրավորողը կամ համակարգի ադմինիստրատորը կկարողանա ընտրել խնդրի լուծման համար հարմար բան։
Գոնե մակերեսային պատկերացում կազմելու համար, թե ինչ են աշխատում VFS-ները գործող համակարգի վրա, փորձեք vfscount
կամ vfsstat
. Սա ցույց կտա, ասենք, տասնյակ զանգեր vfs_open()
իսկ «նրա ընկերները» տեղի են ունենում բառացիորեն ամեն վայրկյան։
vfsstat.py
Python-ի սկրիպտ է՝ C կոդի ներդիրներով, որը պարզապես հաշվում է VFS ֆունկցիայի կանչերը:
Եկեք ավելի չնչին օրինակ բերենք և տեսնենք, թե ինչ է տեղի ունենում, երբ USB ֆլեշ կրիչը տեղադրում ենք համակարգչի մեջ, և համակարգը հայտնաբերում է այն:
Օգտագործելով eBPF, դուք կարող եք տեսնել, թե ինչ է տեղի ունենում
/sys
երբ տեղադրվում է USB ֆլեշ կրիչ: Պարզ և բարդ օրինակ է ներկայացված այստեղ։
Վերևում ներկայացված օրինակում. bcc
գործիք sysfs_create_files()
. Մենք դա տեսնում ենք sysfs_create_files()
գործարկվել է օգտագործելով kworker
հոսք՝ ի պատասխան այն բանի, որ ֆլեշ կրիչը տեղադրվել է, բայց ի՞նչ ֆայլ է ստեղծվել։ Երկրորդ օրինակը ցույց է տալիս eBPF-ի հզորությունը: Այստեղ trace.py
Տպում է միջուկի հետագիծը (-K տարբերակ) և ստեղծված ֆայլի անունը sysfs_create_files()
. Մեկ դրույթի ներդրումը C կոդ է, որը ներառում է հեշտությամբ ճանաչելի ձևաչափի տող, որը տրամադրվում է Python սկրիպտի կողմից, որն աշխատում է 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 խորհրդանշական հղում:
Այսպիսով, ո՞րն է իրադարձությունների ֆայլի իմաստը: Օգտագործումը disk_add_events ()
, և կամ "media_change"
Կամ "eject_request"
կարող է արձանագրվել իրադարձության ֆայլում: Այստեղ միջուկի բլոկի շերտը օգտվողների տարածքին տեղեկացնում է, որ «սկավառակը» հայտնվել և դուրս է եկել: Ուշադրություն դարձրեք, թե որքան տեղեկատվական է այս հետազոտական մեթոդը՝ USB կրիչ տեղադրելով, համեմատած այն բանի հետ, թե ինչպես են աշխատում իրերը զուտ աղբյուրից:
Միայն կարդալու արմատային ֆայլային համակարգերը միացնում են ներկառուցված սարքերը
Իհարկե, ոչ ոք չի անջատում սերվերը կամ իր համակարգիչը՝ վարդակից հանելով վարդակից: Բայց ինչու? Դա պայմանավորված է նրանով, որ մոնտաժված ֆայլային համակարգերը ֆիզիկական պահեստավորման սարքերում կարող են հետաձգված գրել, և տվյալների կառուցվածքները, որոնք գրանցում են իրենց վիճակը, կարող են չհամաժամեցվել պահեստում գրվածների հետ: Երբ դա տեղի ունենա, համակարգի սեփականատերերը պետք է սպասեն մինչև հաջորդ բեռնումը կոմունալ ծրագիրը գործարկելու համար: fsck filesystem-recovery
իսկ վատագույն դեպքում՝ տվյալների կորստի։
Այնուամենայնիվ, մենք բոլորս գիտենք, որ շատ IoT սարքեր, ինչպես նաև երթուղիչներ, թերմոստատներ և մեքենաներ, այժմ աշխատում են Linux-ով: Այս սարքերից շատերը չունեն օգտատիրոջ միջերես, և դրանք «մաքուր» անջատելու միջոց չկա: Պատկերացրեք, որ մեքենան գործարկեք մարտկոցով, երբ կառավարող միավորը միացված է fsck
ե՞րբ է շարժիչը վերջապես սկսում աշխատել: Իսկ պատասխանը պարզ է. Ներկառուցված սարքերը հիմնվում են արմատային ֆայլային համակարգի վրա ro-rootfs
(միայն կարդալու արմատային ֆայլային համակարգ)):
ro-rootfs
առաջարկում են բազմաթիվ առավելություններ, որոնք ավելի քիչ ակնհայտ են, քան իսկությունը: Առավելություններից մեկն այն է, որ չարամիտ ծրագրերը չեն կարող գրել /usr
կամ /lib
, եթե ոչ մի Linux պրոցես չի կարող այնտեղ գրել։ Մյուսն այն է, որ հիմնականում անփոփոխ ֆայլային համակարգը կարևոր է հեռավոր սարքերի դաշտային աջակցության համար, քանի որ աջակցող անձնակազմը հիմնվում է տեղական համակարգերի վրա, որոնք անվանապես նույնական են դաշտային համակարգերին: Թերևս ամենակարևոր (բայց նաև առավել նենգ) առավելությունն այն է, որ ro-rootfs-ը ստիպում է ծրագրավորողներին որոշել, թե որ համակարգի օբյեկտներն անփոփոխ կլինեն համակարգի նախագծման փուլում: Ro-rootf-ների հետ աշխատելը կարող է անհարմար և ցավոտ լինել, քանի որ const փոփոխականները հաճախ ծրագրավորման լեզուներում են, բայց դրանց առավելությունները հեշտությամբ արդարացնում են լրացուցիչ ծախսերը:
ստեղծում rootfs
Միայն կարդալու համար անհրաժեշտ է լրացուցիչ ջանք ներդրված մշակողների համար, և հենց այստեղ է պատկերված VFS-ը: Linux-ը պահանջում է, որ ֆայլերը լինեն /var
գրավոր էին, և ի լրումն, շատ հայտնի հավելվածներ, որոնք աշխատում են ներկառուցված համակարգերով, կփորձեն ստեղծել կոնֆիգուրացիա dot-files
в $HOME
. Տնային գրացուցակում կազմաձևման ֆայլերի լուծումներից մեկը սովորաբար դրանք նախապես ստեղծելն ու ներկառուցելն է rootfs
: Համար /var
Հնարավոր մոտեցումներից մեկն այն է տեղադրել առանձին գրավոր միջնորմի վրա, մինչդեռ /
տեղադրված է միայն կարդալու համար: Մեկ այլ հանրաճանաչ այլընտրանք է կապի կամ ծածկույթի ամրացումների օգտագործումը:
Կապակցվող և շարվող ամրակներ, դրանց օգտագործումը տարաներով
Հրամանի կատարում man mount
Դա լավագույն միջոցն է իմանալու կապակցվող և վերադրվող մոնտաժների մասին, որոնք ծրագրավորողներին և համակարգի ադմինիստրատորներին հնարավորություն են տալիս ստեղծել ֆայլային համակարգ մի ճանապարհով, այնուհետև այն ներկայացնել մյուսի հավելվածներին: Ներկառուցված համակարգերի համար սա նշանակում է ֆայլեր պահելու հնարավորություն /var
միայն կարդալու համար նախատեսված ֆլեշ կրիչի վրա, բայց վերադիր կամ կապակցվող մոնտաժային ուղի tmpfs
в /var
բեռնելիս այն թույլ կտա հավելվածներին այնտեղ գրառումներ գրել (scrawl): Հաջորդ անգամ, երբ միացնեք փոփոխությունները /var
կկորչի. Ծածկույթի ամրացումը ստեղծում է միություն միջև tmpfs
և հիմքում ընկած ֆայլային համակարգը և թույլ է տալիս թվացյալ փոփոխություններ կատարել առկա ֆայլերում ro-tootf
Մինչդեռ ամրացվող ամրակը կարող է դատարկել նորերը tmpfs
թղթապանակներ, որոնք տեսանելի են որպես գրելու հնարավորություն ro-rootfs
ուղիները. Մինչդեռ overlayfs
սա է ճիշտը (proper
) ֆայլային համակարգի տեսակը, ամրացվող տեղադրումը ներդրված է
Ելնելով ծածկույթի և կապակցվող լեռնաշղթայի նկարագրությունից՝ ոչ ոք չի զարմանում դրանում mountsnoop
- ից bcc
.
Մարտահրավեր system-nspawn
գործարկում է բեռնարկղը mountsnoop.py
.
Տեսնենք, թե ինչ եղավ.
Գործարկել mountsnoop
Մինչ բեռնարկղը «booting» է, ցույց է տալիս, որ կոնտեյների գործարկման ժամանակը մեծապես կախված է միացված մոնտաժից (ցուցադրվում է միայն երկար ելքի սկիզբը):
Այստեղ systemd-nspawn
տրամադրում է ընտրված ֆայլերը procfs
и sysfs
հյուրընկալել դեպի կոնտեյներ՝ որպես դրան տանող ուղիներ rootfs
. Բացառությամբ MS_BIND
դրոշը, որը կարգավորում է կապող մոնտաժը, որոշ այլ դրոշներ լեռան վրա սահմանում են կապը հյուրընկալողի և կոնտեյների անվանատարածքների փոփոխությունների միջև: Օրինակ՝ կապված ամրակը կարող է կամ բաց թողնել փոփոխությունները /proc
и /sys
կոնտեյների մեջ կամ թաքցրեք դրանք՝ կախված զանգից:
Ամփոփում
Linux-ի ներքին գործունեությունը հասկանալը կարող է անհնարին խնդիր թվալ, քանի որ միջուկն ինքնին պարունակում է հսկայական քանակությամբ կոդ՝ մի կողմ թողնելով Linux-ի օգտատերերի տարածքի հավելվածները և համակարգային զանգերի միջերեսները C գրադարաններում, ինչպիսիք են. glibc
. Առաջընթացի ուղիներից մեկն է կարդալ մեկ միջուկի ենթահամակարգի ելակետային կոդը՝ շեշտը դնելով համակարգային զանգերի և օգտագործողի տարածքի վերնագրերի, ինչպես նաև միջուկի հիմնական ներքին միջերեսների, օրինակ՝ աղյուսակի հասկանալու վրա: file_operations
. Ֆայլերի գործողությունները ապահովում են «ամեն ինչ ֆայլ է» սկզբունքը, ինչը հատկապես հաճելի է դարձնում դրանք կառավարելը: C միջուկի աղբյուրի ֆայլերը վերին մակարդակի գրացուցակում fs/
ներկայացնել վիրտուալ ֆայլային համակարգերի ներդրում, որոնք փաթաթման շերտ են, որն ապահովում է լայն և համեմատաբար պարզ համատեղելիություն հանրաճանաչ ֆայլային համակարգերի և պահեստավորման սարքերի միջև: Linux-ի անվանատարածքների միջոցով կապելը և ծածկույթի տեղադրումը VFS-ի կախարդանքն է, որը հնարավոր է դարձնում միայն կարդալու բեռնարկղերի և արմատային ֆայլային համակարգերի ստեղծումը: Համակցված աղբյուրի կոդի, eBPF հիմնական գործիքի և դրա միջերեսի ուսումնասիրության հետ bcc
առանցքային հետախուզումն ավելի հեշտ է, քան երբևէ:
Ընկերներ, գրեք, այս հոդվածը ձեզ օգտակա՞ր էր։ Միգուցե որևէ մեկնաբանություն կամ դիտողություն ունեք: Իսկ Linux Administrator դասընթացով հետաքրքրվողներին հրավիրում ենք
Source: www.habr.com