Kritik Sachdeva
I’m Kritik Sachdeva, currently working as a Support Professional at IBM. I’ve been working with Ceph & OpenShift for the past 5 years, and since college I had a great interest in technologies like K8s, containers, or Ceph.
Since then, I’ve enjoyed exploring how different technologies can be integrated to solve real-world problems/
Over the last couple of years, I’ve had the opportunity to speak at various community events & these experiences had helped me grow both technically and personally.
Session
Observability stacks have gotten good at CPU, memory, and network — but storage is still where the picture goes dark. When a workload stalls on I/O, device-level tools like iostat or blktrace tell you the disk was busy; they don't tell you which service caused it, or where in the stack the latency actually accrued: a slow fsync, writeback pressure in the page cache, a filesystem journal commit, or a saturated block queue.
This talk follows a single write from the syscall boundary down to the block layer, using eBPF to instrument each handoff — VFS, the filesystem, the page cache, and block I/O submission and completion — without patching applications or running a custom kernel. We'll look at which attach points (tracepoints, fentry/fexit, kprobes) give honest per-layer latency, how to keep the measurement overhead from biasing the result, and how to attribute the latency back to the responsible cgroup or systemd service instead of an aggregate line on a dashboard. Examples range from fsync-heavy database commits to large sequential writes that look fine at the device level but stall well above it.
Attendees will leave with a concrete method for turning storage from a black box into a traceable path — and an honest sense of where eBPF helps, and where it still can't see.