sysfs（システムファイルシステム）は、Linux 2.6カーネルで導入された仮想ファイルシステムで、デバイスやドライバ、バス、クラスといったカーネルオブジェクトの情報を構造化された形で公開するインターフェイスです。/sys以下にマウントされ、各カーネルオブジェクトが1つのディレクトリ、その属性が1つのファイルというシンプルな原則に従って整理されています。udevによる動的デバイス管理、ホットプラグ対応、電源管理、ネットワークインターフェイス制御などの基盤として機能し、/procが歴史的に抱えていた雑然とした構造の問題を整理した、現代Linuxを支える重要な仕組みです。
この記事の目次
- sysfsを支える3つの主要ディレクトリ階層
- sysfsを活用する基本操作のフロー
- sysfsを扱う際の重要な留意点
- /procと/sys（sysfs）の設計思想の対比
- まとめ
sysfsを支える3つの主要ディレクトリ階層
/sys/devices は実際のハードウェアトポロジを反映したディレクトリ階層で、PCIバス、USBバス、プラットフォームデバイス、仮想デバイス（virtual）などの実体がぶら下がります。例えば /sys/devices/pci0000:00/0000:00:1f.6 のように、バス番号やデバイス番号を含むパスでハードウェアの物理的な位置関係を辿れます。実体としては各デバイスがここに存在し、他の階層はここへのシンボリックリンクとして構成されています。
/sys/class は同じ役割を持つデバイスを横断的に並べたビューを提供します。/sys/class/net には全ネットワークインターフェイスが、/sys/class/block にはブロックデバイスが、/sys/class/tty にはシリアル端末がリンクされており、用途別の横串アクセスを容易にします。/sys/block や /sys/dev も同様にショートカット的な役割を担います。これらの抽象化が、ip コマンドや udev ルール、systemd の各種ユニットを実装する際の堅実な基盤となっています。
sysfsを活用する基本操作のフロー
sysfsを操作する最初のステップは、対象デバイスがどこに公開されているかを把握することです。ネットワークインターフェイスeth0であれば /sys/class/net/eth0/ 配下に、addressやmtu、operstate、statisticsなどの属性ファイルが並びます。catで読み取れば現在値が、echoで書き込めば動的に変更が反映されるものもあります（書き込み可能かは属性次第）。lsblkやip、udevadm info といったツールも内部的にsysfsを参照しています。
より高度な用途では、udevルールと組み合わせた自動化が定番です。udevadm info -a -p $(udevadm info -q path -n /dev/sda) で対象デバイスに辿り着くまでの属性チェーン（ATTR、SUBSYSTEM、KERNEL）を確認し、これらを /etc/udev/rules.d/ のルールに記述すれば、特定デバイスへの命名・パーミッション・所有者付与・スクリプト起動などを宣言的に制御できます。電源管理では /sys/devices/.../power/control に auto/on を書き込み、SSDのI/Oスケジューラ変更には /sys/block/sda/queue/scheduler を編集するなど、sysfs経由でカーネル挙動を細かく調整できるのが大きな魅力です。
sysfsを扱う際の重要な留意点
sysfsを扱う際にまず押さえるべきは、1ファイル1属性という原則です。/proc では複数情報が1ファイルに同居することが多かった反省を踏まえ、sysfsでは各ファイルが単一の値またはごく限定的なフォーマットを表すよう設計されています。これによりスクリプトでのパースが容易になり、ツールチェーン全体の品質向上に寄与しています。一方でカーネルバージョンの変化に伴ってディレクトリ構造や属性名が変わることがあるため、長期運用のスクリプトではパス取得をハードコードしすぎないよう注意が必要です。
属性ファイルへの書き込み挙動も慎重な確認が要ります。/sys/class/net/eth0/mtu に書けばMTUを変更できますが、これは一時的な変更にとどまり再起動で失われます。永続化には NetworkManager や systemd-networkd、ip コマンドを伴うネットワーク設定の書き換えが必要です。同様にI/Oスケジューラや電源管理の設定もudevルールやsystemd unitに落とし込むのが定石です。また /sys 配下にはシンボリックリンクが多用されており、実体は /sys/devices 配下にあります。realpath で実体を確認することで、誤って同じデバイスを別パス経由で複数回扱ってしまう事故を防げます。
/procと/sys（sysfs）の設計思想の対比
/procがプロセス情報を発祥とする「何でも置き場」として育ったのに対し、sysfsはカーネルオブジェクトモデル（kobject）を基盤とし、明確な設計原則に従って整然と構築されています。デバイスとドライバ、バス、クラスといった主要概念がそのままディレクトリ階層に対応し、新しいハードウェアやサブシステムが追加されてもパターンが崩れにくい点が特徴です。
この整理されたモデルにより、udev・systemd・NetworkManagerなどのユーザー空間ツールはsysfsを前提に堅牢な動的デバイス管理を実装できます。とはいえ /proc が完全に置き換えられたわけではなく、プロセス情報やカーネルランタイムパラメータは依然として /proc に集約されており、両者は補完関係にあります。実務上は「プロセスとカーネル設定なら/proc、デバイスとサブシステムなら/sys」という大まかな住み分けを理解しておけば、必要な情報に素早く辿り着けます。トラブルシュート効率を大きく左右するため、sysfsの構造を一度俯瞰しておく価値は十分にあります。
まとめ
sysfsは、Linuxカーネルが管理する豊富なデバイス情報を、シンプルかつ整理された形でユーザー空間へ公開するための基盤です。udevとの密接な連携により動的デバイス管理を支え、ネットワーク・ストレージ・電源管理など多岐にわたる運用を1ファイル1属性の素直な構造で表現します。/procとの役割分担を理解し、必要な属性パスを覚えておけば、Linuxの挙動制御は格段に見通しがよくなります。表からは見えませんが、現代Linux運用の屋台骨を支える重要な仕組みです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント