Linux の仮想ファイル システム: なぜ必要で、どのように機能するのでしょうか? パート2

皆さん、こんにちは。今回は出版物「Linux の仮想ファイル システム: なぜ必要で、どのように機能するのか?」の第 XNUMX 部を共有します。 最初の部分を読むことができます ここで。 この一連の出版物は、コースでの新しいストリームの開始に合わせて発行されることをお知らせします。 「Linux管理者」、もうすぐ始まります。

eBPF および bcc ツールを使用して VFS を監視する方法

カーネルがファイルに対してどのように動作するかを理解する最も簡単な方法 sysfs ARM64 を実際に見るのが最も簡単な方法は、eBPF を使用することです。 eBPF (Berkeley Packet Filter の略) は、以下で実行される仮想マシンで構成されます。 コア、特権ユーザーがリクエストできる (query) コマンドラインから。 カーネル ソースは、カーネルで何ができるかを読者に伝えます。 ロードされたシステム上で eBPF ツールを実行すると、カーネルが実際に何を行っているかがわかります。

幸いなことに、eBPF の使用はツールの助けを借りて非常に簡単に開始できます。 BCC、一般配布からパッケージとして入手可能 Linux そして詳細に文書化されています バーナード・グレッグ。 ツール bcc は、C コードを少し挿入した Python スクリプトです。つまり、両方の言語に精通している人なら誰でも簡単に変更できます。 で bcc/tools Python スクリプトは 80 個あります。これは、開発者またはシステム管理者が問題の解決に適したものを選択できる可能性が高いことを意味します。
実行中のシステム上で VFS がどのような作業を行うかについて、少なくとも表面的なアイデアを得るには、次のことを試してください。 vfscount または vfsstat。 これにより、たとえば、数十回の呼び出しが行われたことがわかります。 vfs_open() そして「彼の友達」は文字通り毎秒起こります。

vfsstat.py これは、単純に VFS 関数呼び出しをカウントする C コードが挿入された Python スクリプトです。

もっと簡単な例を挙げて、USB フラッシュ ドライブをコンピュータに挿入し、システムがそれを検出したときに何が起こるかを見てみましょう。

eBPF を使用すると、何が起こっているかを確認できます /sysUSBフラッシュドライブが挿入されているとき。 ここでは、単純な例と複雑な例を示します。

上に示した例では、 bcc инструмент トレース.py コマンドの実行時にメッセージを出力します sysfs_create_files()。 それがわかります sysfs_create_files() を使用して起動されました kworker フラッシュドライブが挿入されたことに応じてストリームが送信されますが、どのようなファイルが作成されましたか? XNUMX 番目の例は、eBPF の威力を示しています。 ここ trace.py カーネルのバックトレース (-K オプション) と作成されたファイルの名前を出力します。 sysfs_create_files()。 単一ステートメントの挿入は、LLVM を実行する Python スクリプトによって提供される、簡単に認識できるフォーマット文字列を含む C コードです。 ジャストインタイムコンパイラ。 この行をコンパイルし、カーネル内の仮想マシンで実行します。 全機能の署名 sysfs_create_files () フォーマット文字列がパラメータの XNUMX つを参照できるように、XNUMX 番目のコマンドでこれを再現する必要があります。 この C コード部分にエラーがあると、C コンパイラから認識可能なエラーが発生します。 たとえば、-l パラメータを省略すると、「BPF テキストのコンパイルに失敗しました。」と表示されます。 C と Python に精通している開発者は、これらのツールを見つけることができます。 bcc 拡張や変更が簡単です。

USB ドライブが挿入されると、カーネル バックトレースにより、PID 7711 がスレッドであることが示されます。 kworkerファイルを作成したのは «events» в sysfs。 したがって、からの呼び出しは、 sysfs_remove_files() ドライブを削除するとファイルが削除されたことが表示されます events、これは参照カウントの一般的な概念に対応します。 同時に閲覧することで、 sysfs_create_link () USB ドライブの挿入中に eBPF を使用すると、少なくとも 48 個のシンボリック リンクが作成されたことが表示されます。

では、イベント ファイルの意味は何でしょうか? 使用法 Cスコープ 検索用 __device_add_disk()、それが何を引き起こすかを示します disk_add_events ()、およびいずれか "media_change"または "eject_request" イベントファイルに記録できます。 ここで、カーネル ブロック層は、「ディスク」が出現して排出されたことをユーザー空間に通知します。 USB ドライブを挿入することによるこの調査方法が、ソースから純粋に物事がどのように機能するかを理解しようとする場合と比較して、どれほど有益であるかに注目してください。

読み取り専用のルート ファイル システムにより組み込みデバイスが可能になります

もちろん、ソケットからプラグを抜いてサーバーやコンピューターの電源を切る人はいません。 しかし、なぜ？ これは、物理ストレージ デバイスにマウントされたファイル システムの書き込みに遅れがあり、その状態を記録するデータ構造がストレージへの書き込みと同期していない可能性があるためです。 この問題が発生した場合、システム所有者は次回の起動までユーティリティを起動するまで待つ必要があります。 fsck filesystem-recovery そして最悪の場合、データが失われる可能性があります。

しかし、多くの IoT デバイス、ルーター、サーモスタット、自動車が現在 Linux を実行していることは誰もが知っています。 これらのデバイスの多くにはユーザー インターフェイスがほとんどまたはまったくなく、それらを「きれいに」オフにする方法はありません。 コントロールユニットに電力が供給されているときに、バッテリーが切れた状態で車を始動することを想像してください。 Linux 絶えず上下に飛び跳ねています。 長い時間をかけずにシステムが起動するのはなぜですか fsck最終的にエンジンが始動するのはいつですか？ そして答えは簡単です。 組み込みデバイスはルート ファイル システムに依存します 読むだけ （略称 ro-rootfs (読み取り専用のルート ファイルシステム))。

ro-rootfs 本物ほど明らかではない多くの利点を提供します。 利点の XNUMX つは、マルウェアが書き込みできないことです。 /usr または /libLinux プロセスがそこに書き込むことができない場合。 もう XNUMX つは、サポート担当者は名目上フィールド システムと同一のローカル システムに依存するため、リモート デバイスのフィールド サポートには、ほとんど不変のファイル システムが重要であるということです。 おそらく、最も重要な (しかし最も潜伏的な) 利点は、ro-rootfs によって開発者がシステムの設計段階でどのシステム オブジェクトを不変にするかを決定する必要があることです。 const 変数はプログラミング言語によく使用されるため、ro-rootfs を使用するのは扱いにくく、面倒な場合がありますが、その利点は追加のオーバーヘッドを簡単に正当化します。

創造 rootfs 読み取り専用では、組み込み開発者には追加の労力が必要であり、ここで VFS が登場します。 Linux ではファイルが次の場所にある必要があります /var 書き込み可能であり、さらに、組み込みシステムを実行する多くの一般的なアプリケーションは構成を作成しようとします。 dot-files в $HOME。 ホーム ディレクトリ内の構成ファイルに対する解決策の XNUMX つは、通常、それらのファイルを事前に生成してビルドすることです。 rootfs。 のために /var 考えられるアプローチの XNUMX つは、別の書き込み可能なパーティションにマウントすることです。 / 読み取り専用でマウントされます。 もう XNUMX つの一般的な方法は、バインド マウントまたはオーバーレイ マウントを使用することです。

リンク可能およびスタック可能なマウント、コンテナーによる使用

コマンド実行 man mount これは、バインド可能なマウントとオーバーレイ可能なマウントについて学ぶ最良の方法です。これにより、開発者やシステム管理者は、あるパスにファイル システムを作成し、それを別のパスのアプリケーションに公開できるようになります。 組み込みシステムの場合、これはファイルを次の場所に保存できることを意味します。 /var 読み取り専用フラッシュ ドライブ上にありますが、オーバーレイまたはリンク可能なマウント パスから tmpfs в /var ロード時に、アプリケーションがそこにメモを書き込むことができるようになります (走り書き)。 次回変更をオンにするときは、 /var 失うだろう。 オーバーレイ マウントは、 tmpfs と基盤となるファイル システムを統合し、既存のファイルに表向きの変更を加えることができます。 ro-tootf 一方、バインド可能なマウントは新しいマウントを空にすることができます tmpfs 書き込み可能として表示されるフォルダー ro-rootfs 方法。 その間 overlayfs これが正しいです(proper) ファイル システム タイプ、バインド可能なマウントは次のように実装されます。 VFS 名前空間.

オーバーレイとリンク可能なマウントの説明に基づいて、誰も驚かないでしょう。 Linuxコンテナ それらは積極的に使用されています。 使用すると何が起こるか見てみましょう systemd-nspawn ツールを使用してコンテナを実行するには mountsnoop から bcc.

挑戦 system-nspawn 実行中にコンテナを起動します mountsnoop.py.

何が起きたのか見てみましょう：

起動する mountsnoop コンテナーが「起動」している間は、コンテナーのランタイムがリンクされているマウントに大きく依存していることを示します (長い出力の先頭のみが表示されています)。

それは systemd-nspawn 選択されたファイルを提供します procfs и sysfs ホストからコンテナへのパスとして rootfs。 しかも MS_BIND バインディング マウントを設定するフラグ、マウント上の他のいくつかのフラグは、ホストとコンテナーの名前空間への変更間の関係を定義します。 たとえば、リンクされたマウントでは、変更をスキップすることができます。 /proc и /sys コンテナに追加するか、呼び出しに応じて非表示にします。

まとめ

Linux の内部動作を理解することは不可能な作業のように思えるかもしれません。カーネル自体には膨大な量のコードが含まれており、Linux ユーザー空間アプリケーションや C ライブラリのシステム コール インターフェイスは別として、 glibc。 進歩する XNUMX つの方法は、システム コールとユーザー空間ヘッダー、およびテーブルなどの主要な内部カーネル インターフェイスを理解することに重点を置いて、XNUMX つのカーネル サブシステムのソース コードを読むことです。 file_operations。 ファイル操作では、「すべてがファイルである」という原則が提供され、管理が特に楽しくなります。 最上位ディレクトリ内の C カーネル ソース ファイル fs/ 仮想ファイル システムの実装は、一般的なファイル システムとストレージ デバイスの間に広範で比較的単純な互換性を提供するラッパー層です。 Linux 名前空間を介したリンクとオーバーレイ マウントは、読み取り専用コンテナーとルート ファイルシステムの作成を可能にする VFS の魔法です。 ソース コード、eBPF コア ツール、およびそのインターフェイスの検査と組み合わせる bcc
コア探査がこれまで以上に簡単になります。

皆さん、この記事は役に立ちましたか? 何かコメントやご意見がございますでしょうか。 Linux 管理者コースに興味がある方は、次のコースにご招待します。 オープンデー、18月XNUMX日に開催されます。

最初の部分。

出所： habr.com