Վիրտուալ ֆայլային համակարգեր Linux-ում. ինչու են դրանք անհրաժեշտ և ինչպես են դրանք աշխատում: Մաս 2

Ողջույն բոլորին, մենք ձեզ հետ կիսվում ենք «Վիրտուալ ֆայլային համակարգեր Linux-ում. ինչու են դրանք անհրաժեշտ և ինչպես են նրանք աշխատում» հրապարակման երկրորդ մասով։ Կարող եք կարդալ առաջին մասը այստեղ. Հիշեցնենք, որ հրապարակումների այս շարքը համընկնում է դասընթացի նոր հոսքի մեկնարկի հետ։ «Linux Administrator», որը մեկնարկում է շատ շուտով։

Ինչպես վերահսկել VFS-ը՝ օգտագործելով eBPF և bcc գործիքներ

Ամենահեշտ ձևը հասկանալու, թե ինչպես է միջուկը գործում ֆայլերի վրա sysfs դա գործնականում տեսնելն է, իսկ ARM64 դիտելու ամենահեշտ ձևը eBPF-ն օգտագործելն է: eBPF (կրճատ՝ Berkeley Packet Filter) բաղկացած է վիրտուալ մեքենայից, որն աշխատում է միջուկը, որը կարող են պահանջել արտոնյալ օգտվողները (query) հրամանի տողից: Միջուկի աղբյուրները ընթերցողին ասում են, թե ինչ կարող է անել միջուկը. բեռնված համակարգի վրա eBPF գործիքների գործարկումը ցույց է տալիս, թե իրականում ինչ է անում միջուկը:

Բարեբախտաբար, eBPF-ի օգտագործումը սկսելը բավականին հեշտ է գործիքների օգնությամբ մ.թ.ա., որոնք հասանելի են որպես փաթեթներ ընդհանուր բաշխումից Linux և մանրամասն փաստաթղթավորված Բեռնարդ Գրեգ. Գործիքներ bcc Python-ի սկրիպտներ են C կոդի փոքր ներդիրներով, ինչը նշանակում է, որ երկու լեզուներին ծանոթ յուրաքանչյուր ոք կարող է հեշտությամբ փոփոխել դրանք: IN bcc/tools Կան Python-ի 80 սկրիպտներ, ինչը նշանակում է, որ ամենայն հավանականությամբ ծրագրավորողը կամ համակարգի ադմինիստրատորը կկարողանա ընտրել խնդրի լուծման համար հարմար բան։
Գոնե մակերեսային պատկերացում կազմելու համար, թե ինչ են աշխատում VFS-ները գործող համակարգի վրա, փորձեք vfscount կամ vfsstat. Սա ցույց կտա, ասենք, տասնյակ զանգեր vfs_open() իսկ «նրա ընկերները» տեղի են ունենում բառացիորեն ամեն վայրկյան։

vfsstat.py Python-ի սկրիպտ է՝ C կոդի ներդիրներով, որը պարզապես հաշվում է VFS ֆունկցիայի կանչերը:

Եկեք ավելի չնչին օրինակ բերենք և տեսնենք, թե ինչ է տեղի ունենում, երբ USB ֆլեշ կրիչը տեղադրում ենք համակարգչի մեջ, և համակարգը հայտնաբերում է այն:

Օգտագործելով eBPF, դուք կարող եք տեսնել, թե ինչ է տեղի ունենում /sysերբ տեղադրվում է USB ֆլեշ կրիչ: Պարզ և բարդ օրինակ է ներկայացված այստեղ։

Վերևում ներկայացված օրինակում. bcc գործիք հետք.py հրամանը գործարկվելիս տպում է հաղորդագրություն 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 խորհրդանշական հղում:

Այսպիսով, ո՞րն է իրադարձությունների ֆայլի իմաստը: Օգտագործումը cscope Որոնման համար __device_add_disk(), ցույց է տալիս, թե ինչ է այն առաջացնում disk_add_events (), և կամ "media_change"Կամ "eject_request" կարող է արձանագրվել իրադարձության ֆայլում: Այստեղ միջուկի բլոկի շերտը օգտվողների տարածքին տեղեկացնում է, որ «սկավառակը» հայտնվել և դուրս է եկել: Ուշադրություն դարձրեք, թե որքան տեղեկատվական է այս հետազոտական ​​մեթոդը՝ USB կրիչ տեղադրելով, համեմատած այն բանի հետ, թե ինչպես են աշխատում իրերը զուտ աղբյուրից:

Միայն կարդալու արմատային ֆայլային համակարգերը միացնում են ներկառուցված սարքերը

Իհարկե, ոչ ոք չի անջատում սերվերը կամ իր համակարգիչը՝ վարդակից հանելով վարդակից: Բայց ինչու? Դա պայմանավորված է նրանով, որ մոնտաժված ֆայլային համակարգերը ֆիզիկական պահեստավորման սարքերում կարող են հետաձգված գրել, և տվյալների կառուցվածքները, որոնք գրանցում են իրենց վիճակը, կարող են չհամաժամեցվել պահեստում գրվածների հետ: Երբ դա տեղի ունենա, համակարգի սեփականատերերը պետք է սպասեն մինչև հաջորդ բեռնումը կոմունալ ծրագիրը գործարկելու համար: fsck filesystem-recovery իսկ վատագույն դեպքում՝ տվյալների կորստի։

Այնուամենայնիվ, մենք բոլորս գիտենք, որ շատ IoT սարքեր, ինչպես նաև երթուղիչներ, թերմոստատներ և մեքենաներ, այժմ աշխատում են Linux-ով: Այս սարքերից շատերը չունեն օգտատիրոջ միջերես, և դրանք «մաքուր» անջատելու միջոց չկա: Պատկերացրեք, որ մեքենան գործարկեք մարտկոցով, երբ կառավարող միավորը միացված է 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) ֆայլային համակարգի տեսակը, ամրացվող տեղադրումը ներդրված է VFS անվանատարածք.

Ելնելով ծածկույթի և կապակցվող լեռնաշղթայի նկարագրությունից՝ ոչ ոք չի զարմանում դրանում Linux կոնտեյներներ դրանք ակտիվորեն օգտագործվում են։ Տեսնենք, թե ինչ է տեղի ունենում, երբ մենք օգտագործում ենք systemd-nspawn բեռնարկղը գործարկել գործիքի միջոցով 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 դասընթացով հետաքրքրվողներին հրավիրում ենք բաց օր, որը տեղի կունենա ապրիլի 18-ին։

Առաջին մասը:

Source: www.habr.com