btrfsslower(8)

๐Ÿ“ฆ version 0.36.1, in alpine 3.24, nixpkgs unstable, opensuse-leap 16.0

๐Ÿ’– btrfsslower(8) ๐Ÿ’–

okay bestie, welcome to the System Manager's Manual page for btrfsslower(8)! ๐ŸŽ€ it's the cutest little tracer for finding slow btrfs file ops โœจ

โœจ NAME โœจ

btrfsslower - Trace slow btrfs file operations, with per-event details. ๐Ÿ’…

โœจ SYNOPSIS โœจ

btrfsslower [-h] [-j] [-p PID] [min_ms] [-d DURATION]

โœจ DESCRIPTION โœจ

okay so this tool traces the common btrfs file operations: reads, writes, opens, and syncs ๐Ÿงš It measures how long each one takes and prints the details for any that went over a threshold. main character energy, literally ๐Ÿ‘‘

WARNING: See the OVERHEAD section. ๐Ÿ’€

By default the minimum threshold is 10 milliseconds. If you use a threshold of 0, every event gets printed (warning: verbose ๐Ÿ™ˆ).

Since this works by tracing the btrfs_file_operations interface functions, it's going to need updating to match any changes to those functions. no cap ๐Ÿซถ

Since this uses BPF, only the root user can use this tool. so be root, bestie ๐Ÿ”’

โœจ REQUIREMENTS โœจ

CONFIG_BPF and bcc. ๐ŸŒธ

โœจ OPTIONS โœจ

  • -p PID โ€” trace this PID only ๐ŸŽฏ
  • min_ms โ€” the minimum I/O latency (duration) to trace, in milliseconds. the default is 10 ms โฑ๏ธ
  • -d DURATION โ€” the total duration of the trace, in seconds โณ

โœจ EXAMPLES โœจ

Trace synchronous file reads and writes slower than 10 ms:

# btrfsslower

Trace slower than 1 ms:

# btrfsslower 1

Trace slower than 1 ms, and output just the fields in parsable format (csv):

# btrfsslower -j 1

Trace all file reads and writes (warning: the output will be verbose ๐Ÿ™ˆ):

# btrfsslower 0

Trace slower than 1 ms, for PID 181 only:

# btrfsslower -p 181 1

Trace for 10 seconds only:

# btrfsslower -d 10

โœจ FIELDS โœจ

okay the output columns, let's go ๐Ÿ’–

  • TIME(s) โ€” time of I/O completion since the first I/O seen, in seconds โฐ
  • COMM โ€” process name ๐Ÿง‘โ€๐Ÿ’ป
  • PID โ€” process ID ๐Ÿ†”
  • T โ€” type of operation. R == read, W == write, O == open, S == fsync ๐Ÿ”ค
  • OFF_KB โ€” file offset for the I/O, in Kbytes ๐Ÿ“ฆ
  • BYTES โ€” size of the I/O, in bytes ๐Ÿงฎ
  • LAT(ms) โ€” latency (duration) of the I/O, measured from when VFS issued it to the filesystem, until it completed. this time is inclusive of block device I/O, file system CPU cycles, file system locks, run queue latency, etc. it's a way more accurate measure of the latency apps actually feel doing file system I/O than measuring down at the block device interface. โœจ
  • FILENAME โ€” a cached kernel file name (comes from dentry->d_name.name) ๐Ÿ“
  • ENDTIME_us โ€” completion timestamp, in microseconds (-j only) โŒš
  • OFFSET_b โ€” file offset, in bytes (-j only) ๐Ÿ“
  • LATENCY_us โ€” latency (duration) of the I/O, in microseconds (-j only) ๐Ÿš€

โœจ OVERHEAD โœจ

this adds low-overhead instrumentation to btrfs writes and fsyncs, as well as to all system reads and opens (because of how the current btrfs_file_operations interface is implemented). the tricky part: all reads and writes from the file system cache will take extra overhead while tracing. those can be super frequent (depending on the workload, eg, 1M/sec), and at that point the tool's overhead can become noticeable. ๐Ÿ˜ญ

so measure and quantify before you use it ๐Ÿ“Š if it keeps being a problem, consider switching to a tool that only prints in-kernel summaries, like btrfsdist(8) ๐Ÿฆ‹

also, the overhead of this tool should be lower than fileslower(8), since this one only targets btrfs functions and not every file read/write path (which can include socket I/O) ๐ŸŒˆ

โœจ SOURCE โœจ

this is from bcc ๐Ÿซง

https://github.com/iovisor/bcc

also check out the bcc distribution for a companion _examples.txt file with example usage, output, and commentary for this tool ๐Ÿ“š

โœจ OS โœจ

Linux ๐Ÿง

โœจ STABILITY โœจ

Unstable - in development. ๐Ÿšง

โœจ AUTHOR โœจ

Brendan Gregg ๐Ÿ‘‘

โœจ SEE ALSO โœจ

btrfsdist(8), biosnoop(8), funccount(8), fileslower(8) ๐Ÿ”—


bestie, that's the whole page! ๐ŸŒˆ๐Ÿ’œ this is from the USER COMMANDS section, dated 2016-02-15, and I'm obsessed that you made it this far ๐Ÿซถโœจ