LIlivueta·Oct 10, 2023
The disk alert stuff seems like a PoC for making sure the tracepoint works as expected, but I think you can get a lot more info from the tracepoint they're using than just the utilization info that is exposed/highlighted by the current frontend.
Look at what they're actually tracing in the kernel (https://github.com/Lakshmipathi/ebpf-diskalert/blob/main/src... / https://elixir.bootlin.com/linux/v5.6/source/block/bio.c#L18...). One of those things is devid, so you can see what disk a write is going to and correlate that to a PID. I did something similar-ish in DTrace on FreeBSD to track down a rogue writer (https://gridfi.re/blog/dtrace-filesystem-from-fd.html). You can probably dig around in the bio struct (https://elixir.bootlin.com/linux/v5.6/source/include/linux/b...) and/or execution context to find cool stuff about the filesystem ope
Read the rest
ration in question.
If anyone reading this knows about eBPF: I'm curious how you'd go about translating a bio struct and/or execution context structs to an actual filesystem path, not just reading the devid. Or, is that the wrong question because at this point we're already down at the block level?
Thinking more about it, I bet there's a probe higher in the vfs stack that'd be better suited for that kind of thing. I really need to sit down and eBPF-ify my DTrace knowledge.