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.
Sessions
For a while, the standard way to run Podman containers under systemd was podman generate systemd. It worked, but the output was static and awkward to maintain. Quadlet replaced it — and most guides stop at "drop an INI file in a directory and your container starts." leaving the machinery a black box.
This talk demystifies that black box, because the internals are exactly what you reach for when things break. Quadlet isn't a daemon. It's a systemd generator that runs at daemon-reload and turns your .container, .pod, and .network files into ordinary .service units.
In session, we'll trace one stack example from end to end, watching a three-line container file expand into a full podman run command, and cross-unit references become injected After=/Wants= dependency edges with name-mangled volumes and networks.
You'll leave knowing exactly what gets generated, why edits need a daemon-reload, how to dump & debug a failing unit yourself, and explain why keeping only the source files under version control is reliable. Less magic, more model.
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.