Как создать виртуальный диск Linux фиксированного размера, который никогда не будет заменен на диск?

Я хочу создать виртуальный диск Linux фиксированного размера, который никогда не будет перезаписываться на диск. Обратите внимание, что мой вопрос не в том, «почему», я хочу это сделать (скажем, например, для образовательных целей или для исследований): вопрос в том, как это сделать.

Как я понимаю, ramfsразмер не может быть ограничен, поэтому он не соответствует моему требованию иметь виртуальный диск фиксированного размера.

Также кажется, что это tmpfs может быть заменено на диск. Так что это не соответствует моему требованию никогда не обмениваться на диск.

Как создать виртуальный диск Linux фиксированного размера, который никогда не будет заменен на диск?

Можно ли, например, создать tmpfsвнутри ramfs(будет ли такое решение соответствовать моим требованиям) и если да, то как?

Обратите внимание, что производительность не является проблемой, и виртуальный диск заполняется и вызывает ошибки «диск заполнен» также не проблема.

Это всего лишь мысль, и у нее больше одного недостатка, но в любом случае ее вполне можно использовать.

Как насчет создания файла образа и файловой системы внутри него поверх ramfs, а затем монтирования образа как устройства цикла? Таким образом, вы можете ограничить размер виртуального диска, просто ограничив размер файла изображения. Например:

$ mkdir -p /ram/{ram,loop}
$ mount -t ramfs none /ram/ram
$ dd if=/dev/zero of=/ram/ram/image bs=2M count=1
1+0 records in
1+0 records out
2097152 bytes (2.1 MB) copied, 0.00372456 s, 563 MB/s
$ mke2fs /ram/ram/image
mke2fs 1.42 (29-Nov-2011)
/ram/ram/image is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
256 inodes, 2048 blocks
102 blocks (4.98%) reserved for the super user
First data block=1
Maximum filesystem blocks=2097152
1 block group
8192 blocks per group, 8192 fragments per group
256 inodes per group

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done
$ mount -o loop /ram/ram/image /ram/loop
$ dd if=/dev/zero of=/ram/loop/test bs=1M count=5
dd: writing `/ram/loop/test': No space left on device
2+0 records in
1+0 records out
2027520 bytes (2.0 MB) copied, 0.00853692 s, 238 MB/s
$ ls -l /ram/loop
total 2001
drwx------ 2 root root   12288 Jan 27 17:12 lost+found
-rw-r--r-- 1 root root 2027520 Jan 27 17:13 test

В приведенном выше (несколько слишком длинном) примере файл изображения создается размером 2 мегабайта, и при попытке записать на него более 2 мегабайт запись просто завершается сбоем, поскольку файловая система заполнена.

Одно очевидное сокращение всего этого, конечно, заключается в том, что здесь есть много дополнительной сложности, но, по крайней мере, для академических целей этого должно быть достаточно.

В (датированной!) Книге «Драйверы устройств Linux» Корбета, Рубини и Кроа-Хартмана есть пример драйвера, который просто выделяет фиксированную область памяти для дурачения. Не файловая система, но ...

Не может быть сделано Вся оперативная память подлежит разбиению по страницам как на аппаратную часть процессора, так и на структуру микроядра Linux. НЕТ законных причин обращаться с памятью иначе. ВСЕ программные алгоритмы МОГУТ быть адаптированы для использования схемы кэширования файлов и страничной памяти. Виртуальные ВСЕГДА лучше и эффективнее.

RAM-диски ограниченного размера идут вразрез с основополагающими принципами виртуального мира. Вы должны предположить, что к файловой системе хоста отправляются только полезные запросы файлов и что все такие запросы имеют одинаковую важность и приоритет в виртуальном мире (единственная модель, которая учитывается).

Математически доказано, что даже процессы в реальном времени соответствуют этому правилу. Если у вас возникла проблема со скоростью, она НИКОГДА не может быть решена путем использования ОЗУ в качестве хранилища == вся хост-система должна работать быстрее от процессора до шины ввода-вывода и до постоянного запоминающего устройства. Все проблемы, кроме искусственных вырожденных вычислений, имеют достаточные ветки и требования к вводу / выводу файлов, чтобы среднее увеличение скорости кэширования ОЗУ было лучшим, что вы можете сделать.