0

I'm aware of tmpfs and what I really need is a disk partition resides on RAM where I could format it with BTRFS.

How can I create a raw device on RAM and format it with any regular filesystem?

Or is only chance creating a raw file on tmpfs, formatting it with a filesystem and mounting through a loop device (source).

mkdir /ramdisks
mount -t tmpfs tmpfs /ramdisks
dd if=/dev/zero of=/ramdisks/disk0 bs=1M count=100
losetup /dev/loop0 /ramdisks/disk0
mke2fs /dev/loop0
...
losetup -d /dev/loop0
rm /ramdisks/disk0

Use Case

I'm using BTRFS for a number of reasons. My current attempt is to use Overlayfs as rootfs (just like Slax does with Aufs) and I want the underlying directory structure be BTRFS.

Slax uses the following trick: While the system is booting,

  1. instead of actual switch_root operation that the normal installations usually do, Slax creates a transient folder and
  2. mounts it as tmpfs (puts it on the RAM),
  3. switch_root to it as if it were the actual filesystem.
  4. Then it does some Kung-Fu: Mounts its "modules" (the squashfs files) to somewhere (say /modules)
  5. Mounts all folders under /modules/ to /union along with a writable changes folder
  6. pivot_root to the /union folder.

What I want is mimicking that, which doesn't require what I asked so far, except: I want to place the changes folder on the RAM with the support of BTRFS goods:

  1. Support snapshotting,
  2. Support btrfs send | btrfs receive
  3. Possibly BTRFS RAID-1
Community
  • 1
ceremcem
  • 2,351
  • I am not sure if the /dev/ramX-type interface is still around; you may want to try instructions found here and then create a file system there, as mentioned here. – AdminBee Feb 17 '20 at 09:15
  • Can you add some detail on why you want it in RAM? I think this may be an XY problem. It may not improve your performance, compared with using a file, withing an existing file-system. – ctrl-alt-delor Feb 17 '20 at 10:11
  • @ctrl-alt-delor I edited my question accordingly. – ceremcem Feb 17 '20 at 14:40
  • Why RAM? (Lack of backing store?, expected performance increase?, other? ) – ctrl-alt-delor Feb 17 '20 at 17:08
  • There are couple of reasons. First, a NAND storage has limited number of write operations. I'm planning to make it last longer by using RAM for heavy operations (like dist-upgrade, etc) and "flush" the data to the permanent storage at periodic cycles and/or if operation succeeds. Secondly, I might keep the changes on the remote and patch the rootfs on boot with a minimum amount of data transferred. When I need to create an LXC container based on current rootfs which would be only saved if it succeeds somehow, it would be way efficient to create it on the RAM. – ceremcem Feb 17 '20 at 17:38
  • @ctrl-alt-delor this doesnt matter. The question is clear and reasonable. Please answer the question as asked. – Lothar Dec 09 '20 at 23:57
  • @Lothar who knows if it matters? Not me, only the OP can know and they seem to have lost interest. – ctrl-alt-delor Dec 10 '20 at 17:22

0 Answers0