Crate disklayer_sqlite

SQLite-backed disk layer implementation.

At this time, this layer is only designed for use in dev/test scenarios!

DISCLAIMER: Stability

There are no stability guarantees around the on-disk data format! The schema can and will change without warning!

DISCLAIMER: Performance

This implementation has only been minimally optimized! Don’t expect to get incredible perf from this disk backend!

Notably:

• Data is stored within a single sectors table as tuples of (sector: INTEGER, sector_data: BLOB(sector_size)). All data is accessed in sector_size chunks (i.e: without performing any kind of adjacent-sector coalescing).
• Reads and writes currently allocate many temporary Vec<u8> buffers per operation, without any buffer reuse.

These design choices were made with simplicity and expediency in mind, given that the primary use-case for this backend is for dev/test scenarios. If performance ever becomes a concern, there are various optimizations that should be possible to implement here, though quite frankly, investing in a cross-platform QCOW2 or VHDX disk backend is likely a far more worthwhile endeavor.

Context

In late 2024, OpenVMM was missing a cross-platform disk backend that supported the following key features:

• Used a dynamically-sized file as the disks’s backing store
• Supported snapshots / differencing disks

While OpenVMM will eventually need to support for one or more of the current “industry standard” virtual disk formats that supports these features (e.g: QCOW2, VHDX), we really wanted some sort of “stop-gap” solution to unblock various dev/test use-cases.

And thus, disklayer_sqlite was born!

The initial implementation took less than a day to get up and running, and worked “well enough” to support the dev/test scenarios we were interested in, such as:

• Having a cross-platform sparsely allocated virtual disk file.
• Having a persistent diff-disk on-top of an existing disk (as opposed to ramdiff, which is in-memory and ephemeral)
• Having a “cache” layer for JIT-accessed disks, such as disk_blob

The idea of using SQLite as a backing store - while wacky - proved to be an excellent way to quickly bring up a dynamically-sized, sparsely-allocated disk format for testing in OpenVMM.

Modules

resolver

Resource resolver for sqlite-backed disk layers.

Structs

FormatOnAttachSqliteDiskLayer

A disk layer backed by sqlite, which lazily infers its topology from the layer it is being stacked on-top of.

FormatParams

Formatting parameters provided to SqliteDiskLayer::new

IncompleteFormatParams

Formatting parameters provided to FormatOnAttachSqliteDiskLayer::new.

SqliteDiskLayer

A disk layer backed entirely by sqlite.