---
title: "Block Devices Explained: Hand the Kernel Chunks, Not Files"
description: "A block device exposes storage as fixed-size addressable chunks and leaves filesystem logic to the kernel. Here is how that split decides latency, correctness, and who interprets each request."
---

# Block Devices Explained: Hand the Kernel Chunks, Not Files

**Type:** [What is it?](https://yomu.fyi/visual-explainers/category/what-is-it.md)

![Diagram showing a block device as a row of fixed-size numbered chunks, with the filesystem mapping names onto chunks above it, and a lower strip contrasting virtio-fs metadata round trips with the ImageFS-blk block device speedups.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/8405169a-d6cc-478f-9536-a9c4ea7442f6/image-afa8c38f-600a-4925-b6e3-19143954ec6c.webp)

> A block device exposes storage as fixed-size addressable chunks and leaves filesystem logic to the kernel. Here is how that split decides latency, correctness, and who interprets each request.

## Explanation

A block device presents storage as an array of fixed-size chunks that can be read or written by address, with no notion of files, directories, or names. Filesystems supply that meaning: they map names onto chunks, cache metadata, and enforce permissions. The split matters because it decides who does the interpretive work. Give a virtual machine a file-level interface and the host mediates every metadata call; give it a block device and the guest kernel runs its own filesystem locally while the host only moves chunks. Knowing where that boundary sits tells you whether a slow build is a storage problem or an ownership problem.

## FAQ

### Does a block device give you transactions or atomic multi-step updates?

No. A block device gives you addressable chunks and individual reads and writes; it has no concept of a multi-step transaction, a schema, or a permission model. Atomicity across several statements is added higher up by filesystems, database engines, or table formats, which is why transactional guarantees and row-level access controls are built above raw storage rather than inside it.

**Tags:** [Block Device](https://yomu.fyi/topic/block-device.md), [Filesystems](https://yomu.fyi/topic/filesystems.md), [Performance](https://yomu.fyi/topic/performance.md), [virtio-fs](https://yomu.fyi/topic/virtio-fs.md), [Virtual Filesystem](https://yomu.fyi/topic/virtual-filesystem.md), [Virtualization](https://yomu.fyi/topic/virtualization.md)

## Related reading

### [Transactions are Generally Available, advancing warehousing on the Lakehouse](https://yomu.fyi/post/transactions-are-generally-available-advancing-warehousing-on-the-lake.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Benjamin Mathew, Prakhar Jain, Sumeet Varma
- Published: Oct 17, 2026
- Type: Announcement

Databricks made multi-statement transactions generally available on Delta Lake and Apache Iceberg tables, providing atomic guarantees for complex, multi-step workflows directly on the lakehouse. Previously, organizations had to rely on separate warehouse systems for these transactional guarantees, adding expensive data movement, duplicate copies, fragmented governance, and custom consistency workarounds. Row-level concurrency enables concurrent transactions to write to the same table as long as they do not update the same row, delivering significantly stronger performance than traditional cloud and legacy warehouses. The transactions are composable with stored procedures, temporary tables, and streaming tables, and they respect Unity Catalog attribute-based access controls including row-level security and column masking on both reads and writes. Fivetran used transactions to remove consistency-repair code for its slowly changing dimension updates using SCD Type 2, and Accolade processes roughly 1,700 transactions daily for claims and liabilities on the governed lakehouse.


### [Introducing the (blazing fast!) native TCP client for .NET](https://yomu.fyi/post/introducing-the-blazing-fast-native-tcp-client-for-net.md)
- Company: [Clickhouse](https://yomu.fyi/company/clickhouse.md)
- Published: Oct 16, 2026
- Type: Announcement

ClickHouse has released an experimental native TCP client for .NET, available in the ClickHouse.Driver package. Unlike the HTTP client, which requires two format conversions between column blocks and rows, the TCP client uses the native protocol to transfer data as column blocks, enabling zero-allocation, zero-copy reads and writes. In benchmarks, this achieves 1.5-2x faster speeds, over 99% fewer GC allocations, streamed reads of 1.1 million rows per second (115 million values), and parallel inserts at 877,000 rows per second (832,000 from POCOs), all on modest hardware. The client supports three API tiers—column streaming for maximum performance, POCO mapping with compiled per-column loops, and object arrays—and includes a migration path from HTTP. However, it remains experimental, lacking ADO.NET, binary JSON, JWT authentication, and alternative formats, and it only runs on .NET 8 or later.


### [Building fast filesystems for VMs](https://yomu.fyi/post/building-fast-filesystems-for-vms.md)
- Company: [Modal](https://yomu.fyi/company/modal.md)
- Author: Nitin Maddi
- Published: Oct 16, 2026
- Type: Problem & solution

Modal’s VM Sandboxes originally used virtio-fs on top of ImageFS, a lazy-loading FUSE filesystem. This stack caused severe performance degradation: recursive chown took over a minute instead of seconds, and tools like bun install and ripgrep ran three times slower. Analysis revealed that every metadata operation like chown required three round trips from the guest VM to the host, each incurring approximately 99 µs overhead. Modal replaced virtio-fs with ImageFS-blk, a block-level solution that presents a virtual block device to the guest, letting the kernel manage its own filesystem. The new approach delivers dramatic speedups: chown dropped from 9.87 to 0.21 seconds, and bun install fell from 12.5 to 1.07 seconds, often exceeding even direct ImageFS performance.


### [How our AI Research team uses AI Runtime](https://yomu.fyi/post/how-our-ai-research-team-uses-ai-runtime.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Ethan Tang, Ivan Zhou, Irene Dea, Steven Chen, Bruce Fontaine, Ben Hansen
- Published: Oct 16, 2026
- Type: Problem & solution

Databricks’ AI Research team uses AI Runtime (AIR) to manage hundreds of parallel research workstreams for products like Genie, Smart Routing, and AI Functions, training models from a few billion to nearly a trillion parameters. AIR performs preflight checks on GPU nodes to ensure health and communication before training, and monitors node health during execution to detect issues like NCCL failures or thermal throttling. The AIR CLI and custom Docker containers enable fast experimentation by launching jobs in seconds without rebuilding environments, supporting both supervised fine-tuning and reinforcement learning. MLflow integration automatically tracks experiments, while Unity Catalog FUSE mounting gives governed access to research data across workspaces without changing training code. The team has scaled to agent-led training, where AI agents propose changes, launch trials, and evaluate results, increasing training job volume by 8x across AI Functions research workloads.