dcsnoop.bt(8)

πŸ“¦
version 0.27.0 Β· 3 versions
  • 0.27.0 Β· alpine 3.24, arch rolling, centos-stream 10, centos-stream 9, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 0.14.0 Β· ubuntu jammy
  • 0.20.2 Β· ubuntu noble
, in alpine 3.24, arch rolling, centos-stream 10, centos-stream 9, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– dcsnoop.bt(8) ✨ System Manager's Manual πŸ’–

πŸŽ€ NAME

okay so dcsnoop.bt is the tool that traces directory entry cache (dcache) lookups πŸ‘€ It's built on bpftrace/eBPF, so it's giving low-level kernel detective vibes πŸ”πŸ¦‹

🌸 SYNOPSIS

dcsnoop.bt

✨ DESCRIPTION

bestie, by default this traces every dcache lookup 😭 and shows you which process did the lookup and what filename it asked for πŸ“‚πŸ’…

the output can get super verbose πŸ™ˆ so it's meant for digging deeper into dcache performance beyond what dcstat(8) shows you. dcstat is the one that prints per-second summaries, so think of it as the big-picture friend and dcsnoop as the one who goes full detective mode πŸ•΅οΈβ€β™€οΈ

this uses kernel dynamic tracing of the d_lookup() function. ngl that means it's tied to that function, so it will need updating whenever that function changes πŸ”§

and since this runs on BPF, only the root user can use it. no cap, you need to be root πŸ‘‘


🧚 REQUIREMENTS

you'll need CONFIG_BPF and bcc ready to go πŸ“

πŸ’œ EXAMPLES

Trace all dcache lookups:

# dcsnoop.bt

πŸ¦‹ FIELDS

  • TIME(ms) β€” the time of the lookup, in milliseconds ⏰
  • PID β€” the process ID πŸ†”
  • COMM β€” the process name 🏷️
  • T β€” the type: R means reference, M means miss πŸ’€ a miss prints two lines, one for the reference and one for the miss, so don't panic when you see double 😭
  • FILE β€” the file name component being looked up πŸ“„ this can include trailing pathname components (anything after a /), and those become the subject of later lookups, so it's like a chain of lookups bestie πŸ”—

πŸ”₯ OVERHEAD

okay this part is important, so listen up πŸ‘‚ file name lookups can be super frequent depending on the workload 🌊 this tool prints a line for every failed lookup, and if you add -a, it prints every reference too 😱 the output can be verbose, and the overhead, even though it's optimized to some extent, can go anywhere from noticeable to significant πŸ’€

so this is really only for deeper investigations past what dcstat(8) gives you, and only when you absolutely need it 🫢 measure and quantify the overhead in a test environment before using it. trust me on this one πŸ™

⚠️ seriously, don't just run this on prod and hope for the best. test it first!

🌈 SOURCE

this comes from bpftrace 🌟

https://github.com/bpftrace/bpftrace

also look in the bpftrace distribution for a companion _examples.txt file. it has example usage, output, and commentary for this tool, which is lowkey a must-read πŸ“–

this is the bpftrace version of the bcc tool with the same name. the bcc tool might have more options and customizations if you need extra power πŸ’ͺ

https://github.com/iovisor/bcc

πŸ–₯️ OS

Linux 🐧

🚧 STABILITY

Unstable - in development. so it's still a work in progress, be gentle with it πŸ₯Ί

πŸ‘‘ AUTHOR

written by Brendan Gregg πŸ’–

🫧 SEE ALSO


ok bestie that's the whole thing πŸ’…βœ¨ this page is from the USER COMMANDS section, dated 2018-09-08, and it's all about dcsnoop.bt(8) 🌸 stay curious and stay iconic πŸ¦‹πŸ’œ