In the last post I showed how you can combine nbdfuse with nbdkit’s RAM disk to mount a RAM disk as a local file. In a talk I gave at FOSDEM last year I described creating these absurdly large RAM-backed filesystems and you can do the same thing now to create ridiculously big “files”. Here’s a 7 exabyte file:
$ touch /var/tmp/disk.img $ nbdfuse /var/tmp/disk.img --command nbdkit -s memory 7E & $ ll /var/tmp/disk.img -rw-rw-rw-. 1 rjones rjones 8070450532247928832 Nov 4 13:37 /var/tmp/disk.img $ ls -lh /var/tmp/disk.img -rw-rw-rw-. 1 rjones rjones 7.0E Nov 4 13:37 /var/tmp/disk.img
What can you actually do with this file, and more importantly does anything break? As in the talk, creating a Btrfs filesystem boringly just works. mkfs.ext4 spins using 100% of CPU. I let it go for 15 minutes but it seemed no closer to either succeeding or crashing. Update: As Ted pointed out in the comments, it’s likely I didn’t mean mkfs.ext4 here, which gives an appropriate error, but mkfs.xfs which consumes more and more space, appearing to spin.
Emacs said:
File disk.img is large (7 EiB), really open? (y)es or (n)o or (l)iterally
and I was too chicken to find out what it would do if I really opened it.
I do wonder if there’s a DoS attack here if I leave this seemingly massive regular file lying around in a public directory.