jammy (1) nbdkit-memory-plugin.1.gz

Provided by: nbdkit_1.24.1-2ubuntu4_amd64 bug

NAME

       nbdkit-memory-plugin - nbdkit virtual memory (RAM disk) plugin

SYNOPSIS

        nbdkit memory [size=]SIZE [allocator=sparse|...]

DESCRIPTION

       "nbdkit-memory-plugin" is a plugin for nbdkit(1) which stores a single disk image in virtual memory, and
       discards it when nbdkit exits.  This plugin can be used for testing or where you don't care about the
       final content of the disk image.

       All nbdkit clients will see the same disk content, initially all zeroes.

       By default the disk image is stored in memory using a sparse array.  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.  Other allocators are available, see "ALLOCATORS" below.  All allocators store the image in
       memory.  If you want to allocate more space than this use nbdkit-file-plugin(1) backed by a temporary
       file instead.

       Using the sparse allocator the virtual size can be as large as you like, up to the maximum supported by
       nbdkit (2⁶³-1 bytes).  This limit is tested when nbdkit is compiled, and it should work on all platforms
       and architectures supported by nbdkit.

EXAMPLES

       Create a one gigabyte sparse RAM disk:

        nbdkit memory 1G

       If you want to loop mount the above disk, see nbdkit-loop(1).

       Create the largest possible RAM disk:

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

PARAMETERS

       [size=]SIZE
           Specify the virtual size of the disk image.

           This parameter is required.

           "size=" is a magic config key and may be omitted in most cases.  See "Magic parameters" in nbdkit(1).

       allocator=sparse
       allocator=malloc[,mlock=true]
       allocator=zstd
           (nbdkit ≥ 1.22)

           Select the backend allocation strategy.  See "ALLOCATORS" below.  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, look at nbdkit-data-plugin(1) instead.  Note by "small" this does not mean that the virtual disk
       image must be small, but that the amount of data initially stored sparsely is small enough to specify on
       the command line.

   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):

        $ 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

ALLOCATORS

       Since nbdkit ≥ 1.22 several allocation strategies are available using the "allocator" parameter.

       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.  However it should also be reasonably efficient for normal disk
           sizes.

           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.

       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.

           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.

           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.

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

VERSION

       "nbdkit-memory-plugin" first appeared in nbdkit 1.2.

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).

AUTHORS

       Richard W.M. Jones

       Copyright (C) 2017-2020 Red Hat Inc.

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.