lsr: ls with io_uring

Original Article ↗ Hacker News Discussion ↗

Performance & Benchmark Results

  • lsr (Zig + io_uring) is reported ~70% faster than GNU ls on large directories and issues ~35× fewer syscalls.
  • strace comparisons (in a “calls” directory):
    • ls: 198 syscalls,
    • eza: 476,
    • lsr: 33.
  • Some argue syscall reduction is secondary to wall-clock time; others emphasize that fewer syscalls reduce kernel overhead and contention.
  • Another view: io_uring still does the same work in the kernel; fewer syscalls don’t necessarily mean proportionally less kernel work.

Why Core Tools Don’t All Use io_uring

  • Portability: classic tools target many POSIX-like systems; io_uring is Linux-only and relatively recent.
  • Stability & churn: io_uring’s API keeps expanding, and many prefer to wait to see if it “sticks.”
  • Programming model: effective use generally implies async/event-driven designs; many tools are written in simple synchronous C and would need major refactors.
  • Tool authors may not want to work in C or go through GNU coreutils’ contribution process, so they build separate replacements instead.

Security, Sandboxing & Adoption

  • Multiple participants describe io_uring as a “security nightmare,” citing a long series of kernel vulnerabilities, sandbox escapes, and container escapes.
  • Concerns include: direct user–kernel shared memory, rapidly growing surface area, ability to bypass syscall-oriented security mechanisms (e.g., seccomp), and poorer auditability of batched operations.
  • As a result, many environments (notably some container runtimes and large operators) reportedly disable or restrict io_uring.

Libc, Polyfills & Fallbacks

  • Idea raised: make libc transparently implement POSIX I/O atop io_uring. Pushback:
    • Emulating sync on async often adds extra syscalls (e.g., futex, wakeups) and complexity.
    • If calls are serialized anyway, you lose most of io_uring’s benefits.
  • Some discuss user-space “io_uring emulators” using worker threads and ringbuffers so apps can keep the same API on kernels without io_uring. Others note existing runtimes that fall back to epoll.

Filesystems, NFS & Real Workloads

  • Interest in behavior against NFS or flaky networks: io_uring doesn’t inherently fix blocking semantics or NFS’s “local disk” illusion.
  • Debate over NFS’s design: some see “pretending the network is a disk” as fundamentally flawed; others note all reliability is built from unreliable components anyway.
  • File system choice matters: ext4 can be slow with huge directories; XFS reportedly handles large dirs better. Some users see ls/du taking minutes on millions of files.

Feature Tradeoffs & Ecosystem

  • Users like eza’s rich icons, colors, and type detection; lsr is praised for speed but seen as visually simpler.
  • Suggestions to implement LS_COLORS/dircolors and to build similar io_uring-based versions of cat, find, grep, etc.; mention that tools like bat do far more syscalls than cat.
  • Note that io_uring currently lacks getdents; main benefit for ls-style tools is bulk stat (especially ls -l).

Zig, Tangled & Miscellaneous

  • Some discussion of Zig’s allocator model (passing an allocator interface around; different backends like smp_allocator vs page_allocator).
  • Tangled (the hosting platform, built on atproto/Bluesky) draws interest, but some question whether atproto is truly decentralized given Bluesky-centric auth.