2

One can make a ramdisk in Linux by modprobe brd rd_nr=1 rd_size=$SizeInKB (creates uncompressed /dev/ram0) or by modprobe zram && echo $SizeInBytes >| /sys/block/zram0/disksize (creates compressed /dev/zram0).
These types of ramdisk are both unable to be paged out to a swap device and thus limited to a fraction of the physical memory.

To make a swappable in-memory block device which can grow larger than physical memory, one can use
mkdir -p /run/ramfs && mount -t tmpfs -o size=0 ramfs /run/ramfs && \
truncate --size $SizeInBytes /run/ramfs/ramfs && losetup -f && losetup -f /run/ramfs/ramfs.
This is uncompressed but can be combined with zswap to make it compressed (at least some in-memory part of it).
But this involves the overhead of the tmpfs filesystem and the loopback device.

Is there a better method to make a pageable/swappable (possibly compressed) in-memory block device that avoids the overhead of a filesystem below the block layer ?

Juergen
  • 497
  • 4
  • 21
  • tmpfs is very lightweight and typically built into the kernel. It can be swapped out. (See https://www.kernel.org/doc/html/v5.8/filesystems/tmpfs.html). It does not require a loopback device - for example you can make one using a command like "mount -t tmpfs -o rw,size=1G tmpfs /mount/point – davidgo Mar 19 '21 at 04:28
  • I had no problem creating a tmpfs filesystem larger then my available memory. – davidgo Mar 19 '21 at 04:29
  • @davidgo, how do your comments help me with my question ? – Juergen Mar 19 '21 at 09:17

1 Answers1

1

A way to do it (not sure if it's better than the method you described) is to use this NBD-based RAM disk that I wrote. You would use it like this:

$ nbdkit -U /tmp/sock memory 10G
# nbd-client -unix /tmp/sock /dev/nbd0

This RAM disk is stored as a sparse array so it can be any size up to 8 exabytes. If you add allocator=zstd to the command line then it will be compressed.

There are definitely pros and cons to this. There's going to be a bit more overhead, although performance is pretty good for normal workloads. Having a userspace implementation of the RAM disk does make it easy to tweak and customize. You could even implement deduplication if your workload could benefit from that. (The current implementation does not do deduplication).

Rich
  • 146
  • 2
  • Do you expect the overhead of the socket communication and task switching to two user space processes could be lower than the overhead of the all-in-kernel loopback device and tmpfs filesystem baseline solution in the question ? If yes, we should do some benchmarking ... – Juergen Sep 09 '21 at 19:12
  • I mentioned that the performance would not be as good in the answer. Nevertheless nbd + nbdkit is a very fast solution. The benefits of greater flexibility are important too. – Rich Sep 10 '21 at 20:20