iovisor / iovisor/bcc

python developer tutorial examples/disksnoop.py always reports 0 request size

Open
#3,640 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
22.7k
Forks
4.1k
Avg merge
10d 4h
Merged PRs (30d)
3

Description

I am working through the python developer tutorial with Linux 5.14.0 kernel and it doesn't look like disksnoop.py has the intended behavior. In the output, I found the BYTES column was always 0. Here is some example output (sorry, I can't get it to line up here):

`TIME(s) T BYTES LAT(ms)`
`11019.652824000 R 0 0.46`
`11021.668946000 R 0 0.62`
`11022.053227000 W 0 0.81`
`11022.058897000 R 0 5.60`
`11022.059579000 W 0 0.62`
`11022.062159000 R 0 2.51`

I believe this is because `req->__data_len` is the bytes remaining, and this is 0 when the request is completely finished and execution reaches the `trace_completion` attach point function `blk_account_io_done`. Prior to https://github.com/iovisor/bcc/commit/95c9229ea9f029a1b9e8dcbe86fc67f037c0dfa2 the `trace_completion` was attached to `blk_account_io_completion`, and it looks like that function was called before `req->__data_len` was zero'd.

I tried recording the `req->__data_len` in the `trace_start` function using a second `BPF_HASH`, and then retrieving it in the `trace_completion` function to get reasonable-looking I/O sizes reported. I'm new to bcc/eBPF though, so I don't know if this is the right way to address the issue.

Separately, the `elif bytes_s == "0": ` line to check for a metadata request never seems to evaluate to true. Should this be `elif bytes_s == b"0":` ?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with examples/disksnoop.py, especially the trace_start and trace_completion functions and their blk_account_io_done attachment. Compare the request-size values at those points on Linux 5.14.0, and inspect the metadata check involving bytes_s. Done means disksnoop.py reports the actual I/O sizes and correctly handles metadata requests.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux, python
Domain
observability-sre, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.