[PATCH 0/1] nvmet: add basic in-memory backend support

Hannes Reinecke hare at suse.de
Tue Nov 4 02:36:36 PST 2025


On 11/4/25 09:06, Chaitanya Kulkarni wrote:
> Hi,
> 
> Add a new memory backend (io-cmd-mem.c) that provides RAM-backed storage
> for NVMe target namespaces, enabling high-performance volatile storage
> without requiring physical block devices or filesystem backing.
> 
> * Implementation Overview:
> ==========================
> The memory backend introduces a new namespace configuration option via
> configfs that allows users to create memory-backed namespaces by
> setting the 'mem_size' attribute instead of 'device_path'.
> 1. Lazy Page Allocation
>     - Uses xarray for sparse page storage
>     - Pages are allocated on first write (copy-on-write semantics)
> 2. Configfs Interface
>     New attribute: ${NVMET_CFGFS}/subsystems/<subsys>/namespaces/<ns>/mem_size
>     - Accepts size in bytes (e.g., "1073741824" for 1GB)
>     - Can only be set when namespace is disabled
>     - Mutually exclusive with device_path attribute
>     - Limited to 80% of total system memory for safety
> 3. I/O Command Support
>     - Read
>     - Write
>     - Flush
>     - Discard
>     - Write Zeroes
> 4. Backend Detection Logic
>     Namespace backend is selected based on configuration:
>     - If mem_size is set (no device_path): Use memory backend
>     - If device_path points to block device: Use bdev backend
>     - If device_path points to regular file: Use file backend
> 5. The implementation follows existing nvmet backend pattern with three
>     main entry points:
>     - nvmet_mem_ns_enable(): Initialize namespace with xarray storage
>     - nvmet_mem_ns_disable(): Release all pages and cleanup
>     - nvmet_mem_parse_io_cmd(): Dispatch I/O commands to handlers
> 
> I/O processing uses scatter-gather iteration similar to existing backends,
> with per-page operations that handle alignment and boundary cases.
> 
Question remains: why?
We already have at least two other memory-backed devices (brd, null_blk)
which should do the job just nicely.
Why do we need to add another one?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich



More information about the Linux-nvme mailing list