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

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

Како да го следите VFS користејќи алатки eBPF и bcc

Најлесен начин да се разбере како кернелот работи на датотеки sysfs е да се види во пракса, а најлесниот начин да се види ARM64 е да се користи eBPF. eBPF (кратенка од Беркли пакет филтер) се состои од виртуелна машина што работи внатре јадро, што може да го побараат привилегираните корисници (query) од командната линија. Изворите на јадрото му кажуваат на читателот што може да направи кернелот; извршувањето на алатките eBPF на вчитан систем покажува што всушност прави кернелот.

За среќа, започнувањето со користење на eBPF е прилично лесно со помош на алатки БЦЦ, кои се достапни како пакети од општата дистрибуција Linux и детално документирани Бернард Грег. Алатки bcc се Python скрипти со мали вметнувања на C код, што значи дека секој што е запознаен со двата јазика може лесно да ги измени. ВО bcc/tools Има 80 Python скрипти, што значи дека најверојатно развивач или системски администратор ќе може да избере нешто погодно за решавање на проблемот.
За да добиете барем површна идеја за тоа каква работа работат 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-уред, во споредба со обидот да дознаете како работите функционираат чисто од изворот.

root-датотечните системи само за читање овозможуваат вградени уреди

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

Сепак, сите знаеме дека многу IoT уреди, како и рутери, термостати и автомобили, сега работат со Linux. Многу од овие уреди имаат малку или немаат кориснички интерфејс и не постои начин да ги исклучите „чисто“. Замислете да стартувате автомобил со изумрена батерија кога е напојувањето на контролната единица Linux постојано скокајќи нагоре и надолу. Како е тоа што системот се подига без долго fsckкога конечно почнува да работи моторот? А одговорот е едноставен. Вградените уреди се потпираат на root датотечен систем само за читање (скратено ro-rootfs (root датотечен систем само за читање)).

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

создавање rootfs Само за читање бара дополнителен напор за вградените програмери, и тука доаѓа VFS на сликата. Linux бара датотеките да бидат внатре /var можеше да се запише, а покрај тоа, многу популарни апликации што работат вградени системи ќе се обидат да создадат конфигурација dot-files в $HOME. Едно решение за конфигурациските датотеки во домашниот директориум обично е претходно да се генерираат и да се вградат во нив rootfs. За /var Еден можен пристап е да го монтирате на посебна партиција што може да се запише, додека / монтиран само за читање. Друга популарна алтернатива е да се користат држачи за врзување или преклопување.

Поврзувачки и склопливи држачи, нивна употреба со контејнери

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

Врз основа на описот на преклопот и монтажата што може да се поврзе, никој не е изненаден од тоа Линукс контејнери тие активно се користат. Ајде да видиме што се случува кога користиме systemd-nspawn за да го вклучите контејнерот користејќи ја алатката mountsnoop од bcc.

Повик system-nspawn го вклучува контејнерот додека работи mountsnoop.py.

Ајде да видиме што се случи:

Стартувај mountsnoop додека контејнерот се „подига“ покажува дека времето на работа на контејнерот е многу зависно од поврзаната монтажа (Се прикажува само почетокот на долгиот излез).

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

Заклучок

Разбирањето на внатрешната работа на Linux може да изгледа како невозможна задача, бидејќи самиот кернел содржи огромна количина на код, оставајќи ги настрана апликациите за кориснички простор на Linux и интерфејсите за системски повици во библиотеките C, како на пр. glibc. Еден начин да се постигне напредок е да се прочита изворниот код на еден потсистем на кернелот, со акцент на разбирање на системските повици и заглавијата на корисничкиот простор, како и на главните внатрешни интерфејси на кернелот, како што е табелата file_operations. Операциите со датотеки го обезбедуваат принципот „сè е датотека“, што ги прави особено пријатни за управување. Изворните датотеки на C кернелот во директориумот на највисоко ниво fs/ претставуваат имплементација на виртуелни датотечни системи, кои се слој на обвивка што обезбедува широка и релативно едноставна компатибилност помеѓу популарните датотечни системи и уреди за складирање. Поврзувањето и монтажата на преклоп преку именските простори на Linux е магијата на VFS што овозможува создавање контејнери само за читање и root датотечни системи. Во комбинација со испитување на изворниот код, основната алатка eBPF и нејзиниот интерфејс bcc
што го прави истражувањето на јадрото полесно од кога било.

Пријатели, пишете, дали оваа статија ви беше корисна? Можеби имате некакви коментари или забелешки? И оние кои се заинтересирани за курсот Linux Administrator се поканети Отворен ден, кој ќе се одржи на 18 април.

Првиот дел.

Извор: www.habr.com