nbdkit-memory-plugin(1)

📦
version 1.48.1 · 14 versions
, in fedora 44

💾 nbdkit-memory-plugin — the manual page, bestie edition ✨

okay so this is nbdkit-memory-plugin(1), a page from the nbdkit manual family (section 1, the user commands, iykyk). buckle up 🎀

✨ NAME ✨

nbdkit-memory-plugin — the nbdkit virtual memory (RAM disk) plugin. literally a disk that lives in your RAM. it's giving "i have no object permanence" and honestly? same 🫶

🌸 SYNOPSIS 🌸

nbdkit memory [size=]SIZE [allocator=sparse|malloc|zstd]

💖 DESCRIPTION 💖

nbdkit-memory-plugin is a plugin for nbdkit(1) that stores a single disk image in virtual memory, and — hear me out — discards it when nbdkit exits. gone. poof. no cap 💀. it's the "what happens in RAM stays in RAM (for like, five minutes)" of disk images.

so what's it for? testing, bestie. or any situation where you genuinely do not care about the final content of the disk image. it's the main character of disposable storage 👑

all nbdkit clients will see the same disk content, and it starts out as all zeroes. every single one. no drama, no surprises.

by default the disk image is stored in memory using a sparse array. important caveat: the allocated parts of the disk image cannot be larger than physical RAM plus swap, less whatever is being used by the rest of the system. that's the vibe check right there. other allocators exist though, scroll down to ALLOCATORS ✨. and heads up — all allocators store the image in memory. every single one. if you want to allocate more space than this, use nbdkit-file-plugin(1) backed by a temporary file instead, okay? okay.

using the sparse allocator, the virtual size can be as large as you like, up to the maximum supported by nbdkit (2⁶³-1 bytes 😭 that's not a size that's a personality). this limit is tested when nbdkit is compiled, and it should work on all platforms and architectures supported by nbdkit. slay, cross-platform king 💅

🦋 EXAMPLES 🦋

create a one gigabyte sparse RAM disk:

nbdkit memory 1G

if you want to loop mount the above disk, see nbdkit-loop(1). (go read it, it's right there, i'm not doing it for you 💜)

create the largest possible RAM disk — the final boss:

nbdkit memory $(( 2**63 - 1 ))

🎀 PARAMETERS 🎀

  • [size=]SIZE — specify the virtual size of the disk image. and like, this parameter is required. not optional. not "if you feel like it". required required 🙈. the size= prefix may be omitted in most cases — see "Magic parameters" in nbdkit(1) for the whole tea ☕
  • allocator=sparse
  • allocator=malloc[,mlock=true]
  • allocator=zstd — (nbdkit ≥ 1.22 ✨) select the backend allocation strategy. see ALLOCATORS below for the full breakdown. the default is sparse.

💅 NOTES 💅

🌈 Preloading small amounts of data

if you want an in-memory disk image preinitialized with a small amount of data specified on the command line, go look at nbdkit-data-plugin(1) instead. and ngl, by "small" this does not mean that the virtual disk image must be small — it means that the amount of data initially stored sparsely is small enough to specify on the command line. subtle but crucial, don't come for me 🫶

🌈 Preloading large amounts of data

if you want to preload a large amount of data (eg. a disk image) into the memory plugin, use qemu-img(1) or nbdcopy(1). here's the whole ritual:

$ rm -f pid
$ nbdkit -P pid memory 10G

wait for nbdkit to become ready to accept connections:

$ while [ ! -f pid ]; do sleep 1; done

preload Fedora disk image using qemu-img:

$ virt-builder fedora-28 --size=10G
$ qemu-img convert -p -n fedora-28.img nbd:localhost:10809

if you have libnbd ≥ 1.4, you can use nbdcopy(1) as an alternative:

$ nbdcopy -p fedora-28.img nbd://localhost

obsessed with how clean that is 💖

👑 ALLOCATORS 👑

since nbdkit ≥ 1.22 several allocation strategies are available using the allocator parameter. pick your fighter:

  • allocator=sparse — the disk image is stored in memory using a sparse array. the sparse array uses a simple two level page table with a fixed page size. the allocated parts of the disk image cannot be larger than physical RAM plus swap, less whatever is being used by the rest of the system. the aim of the sparse array implementation is to support extremely large images for testing, although it won't necessarily be efficient for that use case — but it should also be reasonably efficient for normal disk sizes, so like, it's fine ✨

the virtual size of the disk can be as large as you like, up to the maximum supported by nbdkit (2⁶³-1 bytes). 🌌

this is the default, and was the only allocator available before nbdkit 1.22. og behavior 💅

  • allocator=malloc
  • allocator=malloc,mlock=true — the disk image is stored directly in memory allocated using malloc(3) on the heap. no sparseness is possible: you must have enough memory for the whole disk. very large virtual sizes will usually fail 😭. however this can be faster because the implementation is simpler and the locking strategy allows more concurrency. speed vs. memory, the eternal struggle.

if mlock=true is added then additionally the array is locked into RAM using mlock(2) (so it should never be swapped out 👑). this usually requires you to adjust the ulimit(1) associated with the process and on some operating systems may require you to run nbdkit as root. (see also the nbdkit(1) --swap option.)

the mlock=true feature is only supported on some platforms. use nbdkit memory --dump-plugin and check that the output contains mlock=yes.

  • allocator=zstd — the disk image is stored in a sparse array where each page is compressed using zstd compression. assuming a typical 2:1 compression ratio, this allows you to store twice as much real data as allocator=sparse, with the trade-off that the plugin is slightly slower because it has to compress and decompress each page. aside from compression, the implementation of this allocator is similar to allocator=sparse, so in other respects (such as supporting huge virtual disk sizes) it is the same. compressed and unbothered 💖

this allocator is only supported if nbdkit was compiled with zstd support. use nbdkit memory --dump-plugin and check that the output contains zstd=yes.

🍓 FILES 🍓

  • $plugindir/nbdkit-memory-plugin.so — the plugin. that's it, that's the file 🎀

use nbdkit --dump-config to find the location of $plugindir.

⭐ VERSION ⭐

nbdkit-memory-plugin first appeared in nbdkit 1.2. a legend from the start, fr fr 🫶

🌸 SEE ALSO 🌸

nbdkit(1), nbdkit-plugin(3), nbdkit-loop(1), nbdkit-data-plugin(1), nbdkit-file-plugin(1), nbdkit-info-plugin(1), nbdkit-tmpdisk-plugin(1), mlock(2), malloc(3), qemu-img(1), nbdcopy(1).

the whole friend group 🥰

💜 AUTHORS 💜

Richard W.M. Jones 👑

Copyright Red Hat

🦋 LICENSE 🦋

redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • neither the name of Red Hat nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY RED HAT AND CONTRIBUTORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RED HAT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

and that's the whole page bestie 💖 this was nbdkit-memory-plugin(1) from nbdkit-1.48.1, dated 2026-08-29 — go forth and make RAM disks, you absolute icon 🌈✨👑

📦 where this page comes from