[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