Виртуелни систем датотека у Линуку: зашто су потребни и како функционишу? Део 2

Здраво свима, са вама делимо други део публикације „Виртуелни системи датотека у Линуку: зашто су потребни и како функционишу?“ Можете прочитати први део овде. Подсетимо, ова серија публикација је темпирана да се поклопи са покретањем новог тока на курсу "Линук администратор", који почиње врло брзо.

Како пратити ВФС користећи еБПФ и бцц алате

Најлакши начин да разумете како кернел ради на датотекама sysfs је да то видите у пракси, а најлакши начин да гледате АРМ64 је да користите еБПФ. еБПФ (скраћено од Беркелеи Пацкет Филтер) се састоји од виртуелне машине која ради језгро, које привилеговани корисници могу да захтевају (query) из командне линије. Извори кернела говоре читаоцу шта кернел може да уради; покретање еБПФ алата на учитаном систему показује шта кернел заправо ради.

Срећом, почетак коришћења еБПФ-а је прилично једноставан уз помоћ алата бцц, који су доступни као пакети из опште дистрибуције линук и детаљно документована Бернард Грегг. Алати bcc су Питхон скрипте са малим уметањима Ц кода, што значи да свако ко познаје оба језика може лако да их измени. ИН bcc/tools Постоји 80 Питхон скрипти, што значи да ће највероватније програмер или администратор система моћи да изабере нешто погодно за решавање проблема.
Да бисте добили барем површну представу о томе шта ВФС-ови раде на систему који ради, покушајте vfscount или vfsstat. Ово ће показати, рецимо, десетине позива vfs_open() а „његови пријатељи“ се дешавају буквално сваке секунде.

vfsstat.py је Питхон скрипта са уметцима Ц кода која једноставно броји позиве ВФС функција.

Хајде да дамо један тривијални пример и да видимо шта се дешава када убацимо УСБ флеш диск у рачунар и систем га детектује.

Користећи еБПФ можете видети шта се дешава /sysкада је УСБ флеш диск уметнут. Овде је приказан једноставан и сложен пример.

У примеру приказаном изнад, bcc алатка траце.пи штампа поруку када се наредба покрене sysfs_create_files(). То видимо sysfs_create_files() је покренут коришћењем kworker стреам као одговор на чињеницу да је флеш диск уметнут, али која датотека је креирана? Други пример показује моћ еБПФ-а. Ево trace.py Штампа повратни траг кернела (опција -К) и име датотеке која је креирана sysfs_create_files(). Уметање једне изјаве је Ц код који укључује лако препознатљив стринг формата који обезбеђује Питхон скрипта која покреће ЛЛВМ компајлер тачно на време. Он компајлира ову линију и извршава је у виртуелној машини унутар кернела. Потпис пуне функције sysfs_create_files () мора се репродуковати у другој команди тако да стринг формата може да упућује на један од параметара. Грешке у овом делу Ц кода доводе до препознатљивих грешака Ц компајлера. На пример, ако је параметар -л изостављен, видећете „Компилација БПФ текста није успела“. Програмери који су упознати са Ц и Питхон-ом ће пронаћи алате bcc лако проширити и променити.

Када је УСБ диск уметнут, праћење језгра ће показати да је ПИД 7711 нит kworkerкоји је креирао датотеку «events» в sysfs. Сходно томе, позив из sysfs_remove_files() ће показати да је уклањање диск јединице резултирало брисањем датотеке events, што одговара општем концепту бројања референци. Истовремено, гледање sysfs_create_link () са еБПФ-ом док убацујете УСБ диск ће показати да је креирано најмање 48 симболичких веза.

Дакле, која је сврха датотеке догађаја? Употреба цсцопе За претрагу __девице_адд_диск(), показује шта узрокује disk_add_events (), и било "media_change"Или "eject_request" може се снимити у датотеку догађаја. Овде слој блока кернела обавештава кориснички простор да се "диск" појавио и избачен. Обратите пажњу на то колико је овај метод истраживања информативан уметањем УСБ диска, у поређењу са покушајем да схватите како ствари функционишу искључиво из извора.

Роот системи датотека само за читање омогућавају уграђене уређаје

Наравно, нико не искључује сервер или свој рачунар извлачењем утикача из утичнице. Али зашто? То је зато што монтирани системи датотека на физичким уређајима за складиштење могу имати заостајање уписивања, а структуре података које бележе њихово стање можда неће бити синхронизоване са уписима у складиште. Када се то догоди, власници система морају да сачекају до следећег покретања да би покренули услужни програм. fsck filesystem-recovery и, у најгорем случају, губитак података.

Међутим, сви знамо да многи ИоТ уређаји, као и рутери, термостати и аутомобили, сада покрећу Линук. Многи од ових уређаја имају мало или нимало корисничког интерфејса и не постоји начин да се искључе „чисто“. Замислите да покренете аутомобил са истрошеним акумулатором када је напајање контролне јединице линук непрестано скачући горе-доле. Како то да се систем покреће без дугог fsckкада мотор коначно почиње да ради? А одговор је једноставан. Уграђени уређаји се ослањају на основни систем датотека само за читање (скраћено ro-rootfs (основни фајл систем само за читање)).

ro-rootfs нуде многе предности које су мање очигледне од аутентичности. Једна од предности је што злонамерни софтвер не може да пише /usr или /lib, ако ниједан Линук процес не може да упише тамо. Други је да је углавном непроменљив систем датотека критичан за теренску подршку удаљеним уређајима, пошто се особље за подршку ослања на локалне системе који су номинално идентични системима на терену. Можда је најважнија (али и најподмукла) предност то што ро-роотфс приморава програмере да одлуче који системски објекти ће бити непроменљиви у фази пројектовања система. Рад са ро-роотф-овима може бити незгодан и болан, јер су цонст варијабле често у програмским језицима, али њихове предности лако оправдавају додатне трошкове.

стварање rootfs Само за читање је потребан додатни напор за уграђене програмере, и ту се појављује ВФС. Линук захтева да датотеке буду унутра /var били су уписиви, а поред тога, многе популарне апликације које покрећу уграђене системе ће покушати да креирају конфигурацију dot-files в $HOME. Једно решење за конфигурационе датотеке у матичном директоријуму је обично да их унапред генеришете и уградите у њих rootfs. До /var Један од могућих приступа је да се монтира на посебну партицију на коју се може писати, док / монтиран само за читање. Још једна популарна алтернатива је употреба носача за везивање или преклапање.

Носачи који се могу повезати и слагати, њихова употреба у контејнерима

Извршење команде man mount је најбољи начин да научите о повезивим и преклапајућим монтирањима, који програмерима и системским администраторима дају могућност да креирају систем датотека на једној путањи, а затим га изложе апликацијама на другој. За уграђене системе, то значи могућност складиштења датотека /var на флеш диску само за читање, али преклапајућа или повезива путања за монтирање из tmpfs в /var приликом учитавања, омогућиће апликацијама да тамо пишу белешке (шкрабање). Следећи пут када укључите промене у /var ће бити изгубљени. Преклопни носач ствара спој између tmpfs и основни систем датотека и омогућава вам да направите привидне промене у постојећим датотекама у ro-tootf док монтирање које се може везати може учинити нове празним tmpfs фасцикле видљиве као у које се може писати ro-rootfs начине. Док overlayfs ово је оно право (proper) тип система датотека, монтирање које се може везати је имплементирано у ВФС именски простор.

На основу описа преклапања и повезивог носача, нико се томе не чуди Линук контејнери они се активно користе. Да видимо шта се дешава када користимо системд-нспавн да покренете контејнер помоћу алата mountsnoop из bcc.

Изазов system-nspawn покреће контејнер док ради mountsnoop.py.

Да видимо шта се десило:

Покретање mountsnoop док се контејнер "подиже" показује да време извођења контејнера у великој мери зависи од повезивања (приказује се само почетак дугог излаза).

Овде systemd-nspawn пружа изабране датотеке у procfs и sysfs хост до контејнера као путање до њега rootfs. Осим тога MS_BIND заставицу која поставља везујуће монтирање, неке друге заставице на монтирању дефинишу однос између промена у именским просторима хоста и контејнера. На пример, повезано монтирање може или прескочити промене на /proc и /sys у контејнер или их сакријте у зависности од позива.

Закључак

Разумевање унутрашњег функционисања Линук-а може изгледати као немогућ задатак, пошто само језгро садржи огромну количину кода, остављајући по страни апликације Линук корисничког простора и интерфејсе системских позива у Ц библиотекама као што је нпр. glibc. Један од начина да се постигне напредак је читање изворног кода једног подсистема језгра, са нагласком на разумевању системских позива и заглавља корисничког простора, као и главних интерних интерфејса кернела, као што је табела file_operations. Операције са датотекама пружају принцип „све је датотека“, што их чини посебно пријатним за управљање. Изворне датотеке Ц кернела у директоријуму највишег нивоа fs/ представљају имплементацију виртуелних система датотека, који су слој омотача који обезбеђује широку и релативно једноставну компатибилност између популарних система датотека и уређаја за складиштење. Повезивање и монтирање преклапања преко Линук именских простора је магија ВФС-а која омогућава креирање контејнера само за читање и роот система датотека. У комбинацији са прегледом изворног кода, основног алата еБПФ-а и његовог интерфејса bcc
чинећи истраживање језгра лакшим него икад.

Пријатељи, пишите, да ли вам је овај чланак био користан? Можда имате неки коментар или примедбу? А они који су заинтересовани за курс Линук администратора су позвани Отворен дан, који ће се одржати 18. априла.

Први део.

Извор: ввв.хабр.цом