Cześć wszystkim, dzielimy się z Wami drugą częścią publikacji „Wirtualne systemy plików w Linuxie: po co są potrzebne i jak działają?” Pierwszą część można przeczytać . Przypominamy, że ta seria publikacji jest związana z uruchomieniem nowego kursu , który już niedługo się zacznie.
Jak monitorować VFS za pomocą narzędzi eBPF i bcc
Najprostszym sposobem zrozumienia, jak jądro operuje na plikach sysfs – jest obserwowanie tego w praktyce, a najprostszym sposobem na monitorowanie ARM64 jest użycie eBPF. eBPF (od Berkeley Packet Filter) składa się z maszyny wirtualnej uruchomionej w , którą użytkownicy z uprawnieniami mogą wywoływać (query) z wiersza poleceń. Źródła jądra informują czytelnika, co może zrobić jądro; uruchomienie narzędzi eBPF w obciążonym systemie pokazuje, co tak naprawdę robi jądro.
Na szczęście, rozpoczęcie używania eBPF jest dość proste dzięki narzędziom , które są dostępne jako pakiety w ogólnym dystrybucji i są szczegółowo udokumentowane . Narzędzia bcc to skrypty w Pythonie z małymi fragmentami kodu w C, co oznacza, że każdy, kto zna oba języki, może je łatwo modyfikować. W bcc/tools jest 80 skryptów Pythona, co oznacza, że programista lub administrator systemu z pewnością znajdzie coś odpowiedniego do rozwiązania swojego zadania.
Aby uzyskać choćby powierzchowne pojęcie o tym, jaką pracę wykonują VFS w działającym systemie, spróbuj vfscount lub vfsstat. To pokaże, na przykład, że dziesiątki wywołań vfs_open() i „jego przyjaciół” występują dosłownie co sekundę.
vfsstat.pyto skrypt w Pythonie, z fragmentami kodu C, który po prostu zlicza wywołania funkcji VFS.
Podamy bardziej trywialny przykład i zobaczymy, co się dzieje, gdy wkładamy pamięć USB do komputera i system ją rozpoznaje.
Dzięki eBPF można zobaczyć, co się dzieje w
/sys, gdy włożono pamięć USB. Oto prosty i zaawansowany przykład.
W przykładzie pokazanym powyżej, bcc narzędzie wyprowadza komunikat, gdy uruchamiana jest komenda sysfs_create_files().Widzimy, że sysfs_create_files(). zostało uruchomione za pomocą kworker w odpowiedzi na to, że pamięć USB została włożona, ale jaki plik został w tym czasie utworzony? Drugi przykład pokazuje całą moc eBPF. Tutaj trace.py wyprowadza zrzut jądra (kernel backtrace) (opcja -K) oraz nazwę pliku, który został stworzony sysfs_create_files().. Wstawianie w pojedynczych stwierdzeniach to kod w C, obejmujący łatwo rozpoznawalny ciąg formatu udostępniany przez skrypt Pythona, który uruchamia LLVM kompilator just-in-time. Ten ciąg kompiluje i wykonuje w wirtualnej maszynie wewnątrz jądra. Pełna sygnatura funkcji sysfs_create_files() musi być powtórzona w drugiej komendzie, aby ciąg formatu mógł odnosić się do jednego z parametrów. Błędy w tym fragmencie kodu w C prowadzą do rozpoznawalnych błędów kompilatora C. Na przykład, jeśli parametr -l jest pominięty, zobaczysz „Failed to compile BPF text.” Programiści, którzy są dobrze zaznajomieni z C i Pythonem, znajdą narzędzia bcc łatwymi do rozszerzenia i zmiany.
Gdy pendrive jest włączony, zrzut jądra pokaże, że PID 7711 to wątek kworker, który stworzył plik "events" do sysfs. Odpowiednio, wywołanie z sysfs_remove_files() pokaże, że usunięcie nośnika spowodowało usunięcie pliku events, co odpowiada ogólnej koncepcji zliczania odniesień. W tym przypadku, przeglądanie sysfs_create_link() z eBPF podczas włożenia pendrive’a pokaże, że utworzono co najmniej 48 dowiązań symbolicznych.
Jaki więc sens ma plik events? Użycie do wyszukiwania , pokazuje, że wywołuje disk_add_events(), a zarówno "media_change", albo "eject_request" mogą być zapisane w pliku zdarzeń. Tutaj warstwa blokowa jądra informuje przestrzeń użytkownika o pojawieniu się i usunięciu „dysku”. Zauważ, jak informacyjna jest ta metoda badania na przykładzie włożenia pendrive’a w porównaniu do prób ustalenia, jak wszystko działa, wyłącznie na podstawie źródeł.
Systemy plików tylko do odczytu umożliwiają działanie wbudowanych urządzeń
Oczywiście nikt nie wyłącza serwera ani komputera, wyciągając wtyczkę z gniazdka. Ale dlaczego? A to dlatego, że zamontowane systemy plików na fizycznych nośnikach mogą mieć oczekujące zapisy, a struktury danych zapisujące ich stan mogą nie synchronizować się z zapisami w magazynie. Kiedy to się dzieje, właściciele systemu muszą czekać na następne uruchomienie, aby uruchomić narzędzie fsck filesystem-recovery i, w najgorszym przypadku, stracić dane.
Niemniej jednak wszyscy wiemy, że wiele urządzeń IoT, a także routery, termostaty i samochody, teraz działają na systemie Linux. Wiele z tych urządzeń praktycznie nie ma interfejsu użytkownika, a nie ma także możliwości ich „czystego” wyłączenia. Wyobraź sobie uruchomienie samochodu z rozładowaną baterią, gdy zasilanie urządzenia sterującego ciągle skacze w górę i w dół. Jak to możliwe, że system ładuje się bez długiego fsck, gdy silnik w końcu zaczyna działać? Odpowiedź jest prosta. Wbudowane urządzenia polegają na korzeniowej systemie plików (w skrócie ro-rootfs (read-only root filesystem).
ro-rootfs Oferują wiele zalet, które są mniej oczywiste niż autentyczność. Jedną z zalet jest to, że złośliwe oprogramowanie nie może pisać do /usr lub /lib, jeśli żaden proces Linux nie może tam pisać. Inną jest to, że w dużej mierze niezmienna struktura systemu plików jest kluczowa dla wsparcia w terenie zdalnych urządzeń, ponieważ personel pomocniczy korzysta z lokalnych systemów, które nominalnie są identyczne z systemami na miejscu. Być może najważniejszą (ale i najbardziej podstępną) zaletą jest to, że ro-rootfs zmusza programistów do zdecydowania, które obiekty systemowe będą niezmienne, już na etapie projektowania systemu. Praca z ro-rootfs może być niewygodna i bolesna, jak to często ma miejsce z zmiennymi const w językach programowania, ale ich zalety łatwo rekompensują dodatkowe koszty.
Tworzenie rootfs tylko do odczytu wymaga dodatkowego wysiłku ze strony programistów systemów wbudowanych, i właśnie tutaj na scenę wkracza VFS. Linux wymaga, aby pliki w /var były dostępne do zapisu, a ponadto wiele popularnych aplikacji, które uruchamiają wbudowane systemy, będzie próbować tworzyć pliki konfiguracyjne dot-files do $HOME. Jednym z rozwiązań dla plików konfiguracyjnych w katalogu domowym jest ich wstępna generacja i pakowanie w rootfs. Dla /var jednym z możliwych podejść jest zamontowanie go w osobnej partycji, dostępnej do zapisu, podczas gdy sam / jest montowane tylko w trybie tylko do odczytu. Inną popularną alternatywą są montowanie powiązane lub nakładane (bind or overlay mounts).
Montaże powiązane i nakładane, ich wykorzystanie przez kontenery
Wykonanie polecenia man mount to najlepszy sposób, aby dowiedzieć się o montowania powiązanego i nakładanego, które dają programistom i administratorom systemów możliwość tworzenia systemu plików w jednej ścieżce, a następnie udostępniania go aplikacjom w innej. Dla systemów wbudowanych oznacza to możliwość przechowywania plików w /var na pamięci flash dostępnej tylko do odczytu, ale montowanie nakładane lub powiązane z ścieżką z tmpfs do /var podczas uruchamiania umożliwi aplikacjom zapisywanie na tym miejscu (scrawl). Przy następnym uruchomieniu zmiany w /var zostaną utracone. Montowanie nakładane tworzy połączenie pomiędzy tmpfs a dolną warstwą systemu plików i pozwala na rzekome zmiany w istniejących plikach w ro-tootf podczas gdy montowanie powiązane może sprawić, że nowe puste tmpfs foldery będą widoczne jako dostępne do zapisu w ro-rootfs ścieżkach. Podczas gdy overlayfs to odpowiedni (proper) typ systemu plików, montowanie powiązane jest realizowane w .
Na podstawie opisu montowania nakładanego i powiązanego, nikt nie dziwi się, że aktywnie je wykorzystują. Przyjrzyjmy się, co się dzieje, gdy używamy do uruchomienia kontenera, używając narzędzia mountsnoop od bcc.
Wywołanie system-nspawn uruchamia kontener podczas pracy mountsnoop.py.
Zobaczmy, co się wydarzyło:
Uruchomienie mountsnoop podczas 'ładowania' kontenera pokazuje, że środowisko uruchomieniowe kontenera zależy od montowania powiązanego (Wyświetlane jest tylko początki długiego wyjścia).
Tutaj systemd-nspawn udostępnia wybrane pliki w procfs i sysfs gospodarza do kontenera jako ścieżki w jego rootfs. Oprócz MS_BIND flaga, która ustawia montowanie powiązane, inne flagi w montowanym systemie określają związek między zmianami w przestrzeni nazw hosta a kontenera. Na przykład, montowanie powiązane może albo przepuszczać zmiany w /proc i /sys w kontener, albo je ukrywać w zależności od wywołania.
Podsumowanie
Zrozumienie wewnętrznej struktury Linuxa może wydawać się niemal niemożliwe, ponieważ samo jądro zawiera ogromną ilość kodu, nie wspominając o aplikacjach przestrzeni użytkownika Linuxa i interfejsach wywołań systemowych w bibliotekach w języku C, takich jak glibc. Jednym ze sposobów na osiągnięcie postępu jest przeczytanie kodu źródłowego jednej z podsystemów jądra, skupiając się na zrozumieniu wywołań systemowych i nagłówków zwracających się do przestrzeni użytkownika, a także głównych wewnętrznych interfejsów jądra, na przykład tabela file_operations. Operacje plikowe zapewniają zasadę „wszystko jest plikiem”, dlatego zarządzanie nimi jest szczególnie przyjemne. Źródłowe pliki jądra w języku C znajdują się w katalogu głównym fs/ reprezentują implementację wirtualnych systemów plików, które są warstwą powłoki zapewniającą szeroką i stosunkowo prostą zgodność popularnych systemów plików i urządzeń przechowujących. Montowanie związane i nakładanie przez przestrzenie nazw Linuxa to magia VFS, która umożliwia tworzenie kontenerów i systemów plików tylko do odczytu. W połączeniu z nauką kodu źródłowego, narzędzie jądra eBPF i jego interfejs bcc
sprawiają, że badanie jądra jest łatwiejsze niż kiedykolwiek.
Drodzy, dajcie znać, czy ten artykuł był dla Was przydatny? Może macie jakieś komentarze lub uwagi? A tych, którzy są zainteresowani kursem „Administrator Linux”, zapraszamy na , który odbędzie się 18 kwietnia.
Źródło: habr.com
