f2fsslower(8)

💖 f2fsslower(8) 💖

System Manager's Manual ✨

✨ NAME ✨

okay so f2fsslower is the tool that spots slow f2fs file operations and tells you everything about each one 🔍 💅

🎀 SYNOPSIS 🎀

f2fsslower [-h] [-s] [-p PID] [min_ms]

🦋 DESCRIPTION 🦋

bestie, this tool traces the common f2fs 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 🫶

WARNING: see the OVERHEAD section, seriously 😭

By default the minimum threshold is 10 milliseconds 🌸 If you set the threshold to 0, every single event gets printed (warning: it's very verbose, like a chatty group chat 💀).

Since this works by tracing the f2fs_file_operations interface functions, it's going to need updating whenever those functions change 🔧

Since this uses BPF, only the root user can run it 👑

🌈 REQUIREMENTS 🌈

CONFIG_BPF and bcc are needed 💜

✨ OPTIONS ✨

• -p PID — only trace this PID 🎯
• min_ms — the minimum I/O latency (duration) to trace, in milliseconds ⏱️ The default is 10 ms 🌷

🍓 EXAMPLES 🍓

Trace synchronous file reads and writes that are slower than 10 ms:

# f2fsslower

Trace anything slower than 1 ms:

# f2fsslower 1

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

# f2fsslower -s 1

Trace all file reads and writes (warning: the output will be verbose 🙈):

# f2fsslower 0

Trace slower than 1 ms, for PID 181 only 🧚:

# f2fsslower -p 181 1

💅 FIELDS 💅

• TIME(s) — when the I/O completed, counted in seconds from the first I/O seen ⏰
• COMM — the process name 🧑‍💻
• PID — the process ID 🆔
• T — the type of operation. R == read, W == write, O == open, S == fsync 🔤
• OFF_KB — the file offset for the I/O, in Kbytes 📍
• BYTES — the size of the I/O, in bytes 📦
• LAT(ms) — the latency (duration) of the I/O, measured from when VFS issued it to the filesystem, until it completed 🕰️ This time includes block device I/O, file system CPU cycles, file system locks, run queue latency, and so on 🔒 It's a more accurate picture of the latency that applications actually feel when doing file system I/O, compared to measuring down at the block device interface 🎀
• FILENAME — a cached kernel file name (it comes from dentry->d_name.name) 📄
• ENDTIME_us — the completion timestamp, in microseconds (-s only) ⭐
• OFFSET_b — the file offset, in bytes (-s only) 🫧
• LATENCY_us — the latency (duration) of the I/O, in microseconds (-s only) ⚡

🙈 OVERHEAD 🙈

okay, real talk: this adds low-overhead instrumentation to these f2fs operations, including reads and writes from the file system cache 🧠 Those reads and writes can be super frequent (it depends on the workload, eg, 1M/sec 😳), and at that point the overhead of this tool can start to become significant, even if it prints no "slower" events 📉 Measure and quantify before you use it 📏 If it keeps being a problem, consider switching to a tool that only prints in-kernel summaries 🔁

Also, the overhead of this tool should be less than fileslower(8), because this one only targets f2fs functions and not every file read/write path (which can include socket I/O) 🦋

🌸 SOURCE 🌸

This comes from bcc 🫶

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file, which has example usage, output, and commentary for this tool 📚

🖥️ OS 🖥️

Linux 🐧

🧪 STABILITY 🧪

Unstable, still in development 🚧

👩‍💻 AUTHOR 👩‍💻

Ting Zhang 💜

🔗 SEE ALSO 🔗

biosnoop(8), funccount(8), fileslower(8) ✨

---

That's the whole page, bestie! 🌈 It was from the USER COMMANDS section, dated 2022-08-15, and it's the f2fsslower(8) manual, forever iconic 👑💖🦋