sysfs — the Device and Driver Tree

/proc grew organically over decades into a mix of process information, kernel statistics, and tunable parameters, all coexisting without much overall structure. sysfs, mounted at /sys, was introduced later specifically to fix one part of that mess: a clean, properly hierarchical way to expose exactly what devices and drivers the kernel knows about, and how they relate to each other.

What sysfs Actually Represents

Internally, the kernel maintains an object model of every device it knows about — what bus it’s on, what driver is handling it, what type of device it is. sysfs exposes that internal object model directly as a browsable directory tree, using the same VFS mechanism from earlier in this section: no disk storage behind any of it, every file generated live from the kernel’s actual current state.

findmnt /sys

TARGET SOURCE FSTYPE OPTIONS
/sys   sysfs  sysfs  rw,nosuid,nodev,noexec,relatime

The Real Hierarchy: /sys/devices

/sys/devices is the actual, canonical device tree — every device’s true position, organized by the physical bus it’s attached to.

ls /sys/devices

This tends to be a genuinely deep, sprawling structure — reflecting the real physical topology of buses and the devices attached to them, more detail than you’d usually want to browse directly.

The Convenient Views: /sys/class And /sys/block

Browsing the real device tree by physical bus topology is rarely what you actually want day to day. /sys/class groups the exact same underlying devices by function instead — network interfaces together, regardless of which bus they’re physically on; TTYs together; and so on.

ls /sys/class/net

eth0  lo

This should look immediately familiar — the same interface names you’d see from ip link or ip addr elsewhere in this course, here exposed directly through the filesystem instead of through a dedicated command.

cat /sys/class/net/eth0/address

02:42:ac:11:00:02

The interface’s MAC address, read straight from the file backing it — no command needed at all, just cat.

cat /sys/class/net/eth0/operstate

up

The interface’s current operational state — up or down — again, a plain file read rather than a command’s parsed output.

/sys/block works the same way, but for block devices — directly matching device names you already know from the Storage & Disks material:

ls /sys/block

sda  sdb  loop0

A Genuinely Useful Practical Example: Is This Disk An SSD Or A Spinning Drive?

This is one of the more satisfying real uses of sysfs — determining a disk’s underlying type directly, with no specialized tool needed at all:

cat /sys/block/sda/queue/rotational

A 1 means the kernel considers this a rotational (spinning, mechanical) disk. A 0 means it doesn’t — effectively confirming it’s solid-state. This single file answers a question that would otherwise require inspecting hardware specifications or running a dedicated utility, using nothing but cat.

A couple of related, similarly useful attributes in the same directory:

cat /sys/block/sda/size

The device’s size, expressed in 512-byte sectors rather than bytes directly — multiply by 512 to get the actual byte count.

cat /sys/block/sda/queue/scheduler

Shows which I/O scheduler is currently active for this disk, with the active one bracketed — a genuinely deep tuning topic in its own right, but worth knowing this is exactly where that setting lives and can be inspected.

Module Parameters

Loaded kernel modules can expose their own configurable parameters through sysfs as well, under /sys/module:

ls /sys/module/<module-name>/parameters/

Each file here represents one parameter that module accepts, readable (and sometimes writable, depending on how the module defines it) the same way any other sysfs attribute is.

Writable Attributes: The Same Caution As /proc/sys

Just like /proc/sys from the last chapter, plenty of sysfs files aren’t just readable — some are genuinely writable, and writing to them changes live hardware or driver behavior immediately.

echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler

This would change the active I/O scheduler for sda on the spot, no confirmation, no reboot required — and, exactly like /proc/sys, no persistence either. The change reverts the moment the system reboots unless you’ve configured something separately (typically a udev rule or a boot-time script) to reapply it automatically.

A Quick Word On udev

You haven’t been introduced to udev directly in this course, but it’s worth a brief mention here since it leans on sysfs heavily: udev is the subsystem responsible for actually creating device nodes under /dev (the /dev/sda-style paths from the Storage & Disks material) in response to devices appearing or disappearing, and it does so by watching exactly the kind of device and driver information sysfs exposes. This is genuinely deeper territory than this course covers hands-on, but it explains a connection worth having in the back of your mind: sysfs describes what devices exist and their properties; udev acts on that information to manage /dev itself.

procfs vs. sysfs, Side By Side

What’s Next

With both procfs and sysfs covered as reading interfaces, the next chapter goes back to the writable /proc/sys tree from the last chapter — properly this time, using sysctl, the correct tool for making kernel tunable changes that actually survive a reboot.