Kernel Log (dmesg) Size Calculator
Estimate dmesg ring buffer capacity from log_buf_len and how much history it can hold before wrapping.
Inputs
Ring Buffer Size
256 KB
Time Until Wraparound Under Load
9m 42s
Approx. Max Lines Held
2,912
Persistence Note
journald is configured with persistent storage (/var/log/journal) — kernel messages are copied out of the ring buffer and retained on disk, so buffer wraparound does not mean history is permanently lost.
Step by step
Values used
log_buf_len (KB) = 256 KB (common default); Average dmesg Line Size (bytes) = 90; Kernel Messages per Second Under Heavy Load = 5; Persistent journald Storage Enabled? = Yes
Buffer capacity
max_lines_held = log_buf_len_bytes / avg_line_size; seconds_until_wrap = max_lines_held / messages_per_sec
Ring Buffer Size
= 256 KB
Time Until Wraparound Under Load
= 9m 42s
Approx. Max Lines Held
= 2,912
Persistence Note
= journald is configured with persistent storage (/var/log/journal) — kernel messages are copied out of the ring buffer and retained on disk, so buffer wraparound does not mean history is permanently lost.
How it works
The kernel's printk ring buffer (sized by the log_buf_len boot parameter, typically 128KB-1MB depending on distro and hardware) holds recent kernel messages viewable with `dmesg`. It's a fixed-size circular buffer — once full, new messages overwrite the oldest ones, so a burst of kernel messages (driver errors, OOM killer activity, hardware faults) can wrap and permanently lose earlier context within seconds if the buffer is small and the message rate is high. Whether that loss actually matters depends on whether journald (or another log forwarder) has already persisted a copy to disk before the wrap occurs.
Formula
Buffer capacity
max_lines_held = log_buf_len_bytes / avg_line_size; seconds_until_wrap = max_lines_held / messages_per_sec
Frequently Asked Questions
How do I check and change the current dmesg buffer size?
`dmesg -s <bytes>` sets the read buffer size for the dmesg command itself, but the kernel's actual ring buffer size is set at boot via the `log_buf_len=<size>` kernel parameter (e.g. in GRUB config) and cannot be resized at runtime — you can only view/consume what the kernel already allocated.
Why does dmesg output sometimes seem to be missing messages from right after boot?
On systems with heavy early-boot kernel logging (many drivers, verbose debug settings) combined with a small log_buf_len, the ring buffer can wrap before userspace even starts, silently losing the earliest boot messages — increasing log_buf_len via kernel boot parameter is the fix if early-boot diagnostics matter.
Does journald duplicate the entire dmesg ring buffer, or just forward new messages?
journald reads the kernel ring buffer at startup (capturing whatever's currently in it) and then continues forwarding new kernel messages as they arrive via the kmsg device, so if journald starts late (or the buffer wrapped before journald could read it), some very early messages are lost from both dmesg and the journal permanently.
You might also need
- Boot Time CalculatorCommonly used together
- Syslog Storage CalculatorCommonly used together
- Log Rotation Size CalculatorCommonly used together
- Kernel Parameter CalculatorAlso in System Administration
- Kernel Thread CalculatorAlso in System Administration
- Module Dependency CalculatorAlso in System Administration