Создание рам диска linux

Обновлено: 04.07.2024

Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.

Однако до недавнего времени мне не был известен способ, как реализовать подобное для Linux. Нет, безусловно, существует огромное количество линуксовых LiveCD, загружающихся в память при помощи опций ядра toram, copy2ram и т. д., однако это не совсем то. Во-первых, это сжатые файловые системы, обычно squashfs, поэтому любое чтение с них сопровождается накладными расходами на распаковку, что вредит производительности. Во-вторых, это достаточно сложная каскадная система монтирования (так как squashfs — рид-онли система, а для функционирования ОС нужна запись), а мне хотелось по возможности простого способа, которым можно «вот так взять и превратить» любой установленный на жесткий диск Linux в загружаемый целиком в RAM.

Но поскольку установка Debian не является предметом этой статьи, подробно ее описывать не буду.

Такой выбор в общем продиктован тем, что оперативной памяти никогда не бывает много и держать в ней что-то огромное вроде KDE не предполагалось. После установки необходимых для работы программ на жестком диске оказалось занято полтора гигабайта. Установка производилась в один раздел, без раздела swap. Оперативной памяти на компьютере установлено 16 гигабайт.

Собственно, способ

1. В файле /usr/share/initramfs-tools/scripts/local закомментируем строку:
checkfs $ root
и строку:
mount $ -t $ $ $ $
и сразу после нее вставим такой текст:

mkdir /ramboottmp
mount $ -t $ $ $ /ramboottmp
mount -t tmpfs -o size=100% none $
cd $
tar -zxf /ramboottmp/ram.tar.gz
umount /ramboottmp

2. Выполним команду mkinitramfs -o /initrd-ram.img
и после того, как она отработает, вернем файл /usr/share/initramfs-tools/scripts/local в исходное состояние.

3. В файле /etc/fstab закомментируем строку, описывающую монтирование корневого раздела / и вставим такую строку:
none / tmpfs defaults 0 0

4. Загрузим какой-нибудь другой линукс с LiveCD, чтобы полностью отвязаться от испытуемой операционной системы,
и заархивируем весь раздел с ее файловой системой:
cd /mnt/first && busybox tar -czf /mnt/work/ram.tar.gz *
после окончания вернем файл /etc/fstab в исходное состояние.

5. В итоге у нас получился линукс, состоящий всего из трех файлов:
кернела, initrd-ram.img и ram.tar.gz. Местонахождение ram.tar.gz указываем в параметре root= ядра в меню загрузчика grub:
title Linux in RAM
kernel /vmlinuz root=/dev/sdb1
initrd /initrd-ram.img

Это вся инструкция. Необходимые комментарии:
— checkfs закомментируем потому, что нет такого fsck для проверки tmpfs, не написали его;
— busybox tar используем для создания архива вместо простого tar из-за того, что в initrd нет простого tar, распаковывать наш архив будет именно busybox, и существует такой баг, что не сможет распаковать;
— звездочка в командной строке не страшна, так как в корне, обычно, нет скрытых файлов и папок, а в директориях они архивируются.
— /mnt/first — это примонтированный раздел с испытуемой ОС, а /mnt/work/ — это раздел для помещения архива.

Как это работает?

Мы изготовили специальный initrd, который при загрузке создает корневую файловую систему типа tmpfs (в этом вся соль, так как располагается она в оперативной памяти), затем смотрит на указанный в опции root= раздел, берет там файл архива, имя которого захардкожено (ram.tar.gz), и распаковывает из него все дерево ФС на эту tmpfs.

Так ФС оказывается в памяти.

Причем tmpfs обладает выгодными отличиями от рамдисков (в том числе от используемого мной для Windows) — она не блочное устройство, а файловая система, она занимает места в памяти ровно столько, сколько занимают файлы, и динамически увеличиватся, если что-то устанавливать, записывать новые файлы, и уменьшается, если деинсталлировать софт, удалять файлы. Остальная память доступна для работы ОС, программ. А еще Linux понимает, что это УЖЕ память и ее не надо кэшировать. Замечательная вещь!

Преимущества

Да, конечно, кэширование в современных ОС частично решает проблему низкой производительности дисковых устройств, но все равно необходимо время для первого прочтения файла с диска, а также он может быть выгружен из кэша в любое время и тогда понадобится время для его повторного чтения. Размещение же всей ОС в памяти является бескомпромиссным решением, гарантирующим максимально возможную скорость чтения и записи ее файлов. Простейший тест с помощью dd демонстрирует 3 гигабайта в секунду на последовательное чтение и 2 гигабайта в секунду на последовательную запись:

dd if=/dev/zero of=/test bs=1M count=500
524288000 bytes (524 MB) copied, 0.268589 s, 2.0 GB/s

dd if=/test of=/dev/null bs=1M count=500
524288000 bytes (524 MB) copied, 0.167294 s, 3.1 GB/s

Это примерно в 30 раз быстрее, чем HDD, и в 8 раз быстрее, чем SSD.

Продвинутый тест с помощью fio демонстрирует iops 349059 при случайном чтении и complete latency 0.29 микросекунд (латентность на два-три (десятичных) ПОРЯДКА меньше, чем у SSD):

В работе

Вывод команды free в типовой рабочей ситуации:

total used free shared buffers cached
Mem: 16469572 3236968 13232604 2075372 65552 2687436

Сразу после загрузки используется около 2 гигабайт памяти, из которых 1.5 занимает файловая система. При наличии 16 гигабайт ОЗУ имеется большой простор для установки даже больших приложений, как LibreOffice или Blender. Размер файла ram.tar.gz примерно полгига, что позволяет хранить его, кернел и initrd на любой небольшой флешке или на CD. Жесткого диска может вообще не быть. Такая система неубиваема. Но главное — это, конечно, скорость работы.

В заключении тридцатисекундный скринкаст о фактической скорости запуска приложений в такой системе. Нет, это не открытие приложений из трея, это запуск программ с носителя, которым в данном случае является tmpfs:

Что такое RAM-диск?

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

Звучит слишком хорошо, чтобы быть правдой? Что ж, здесь действительно есть нюанс; если вы случайно перезагрузите компьютер или он выйдет из строя, все ваши данные исчезнут. RAM (оперативная память), микросхемы памяти в вашем компьютере, требуют постоянного питания для сохранения информации. Хранилище ОЗУ считается энергозависимым.

Другими словами, RAM-диски подходят для временных приложений или для определенных оптимизаций. Например, когда мы используем тестовые серверы для тестирования программного обеспечения, мы настраиваем RAM-диск, чтобы ускорить выполнение множества параллельных тестов. И даже если бы сервер потерял мощность, потеряно было бы немного; мы бы просто начали еще один тестовый прогон.

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

Кроме того, RAM-диск не работает так же, как выделение / экземпляр tmpfs.

RAM Drive против экземпляра tmpfs

Файл tmpfs также может, но не обязательно, храниться в микросхемах оперативной памяти вашего компьютера. Обычное отображение / dev / shm tmpfs, автоматически настраиваемое при установке большинства, если не всех операционных систем Linux, удобно, но не работает так же, как RAM-диск.

Разница между ними заключается в том, что RAM-диск (на ум приходит термин жесткий) на 100% хранится в реальных микросхемах RAM, тогда как tmpfs хранится в пуле памяти ядра Linux, который может включать такие вещи, как пространство подкачки, которое регулярно располагается. на диске. Хотя ядро, вероятно, оптимизирует весь доступ к пулу, оно по-прежнему дает возможность записи данных либо в физическую ОЗУ, либо на физический ДИСК. И, если он попадет на диск, будет медленнее.

Создание RAM-диска

Первая команда требует sudo, поскольку она делает каталог, возможно, корневым и, по крайней мере, / mnt, которые являются привилегированными / защищенными каталогами. Следующая команда, фактическое монтирование и создание RAM-диска, требует sudo, поскольку монтирование является привилегированной операцией. Мы устанавливаем размер 1 ГБ, используя size = 1g. Мы также указываем, что нам нужен диск типа ramfs (-t ramfs), исходящий от устройства ramfs (как указано вторым ramfs), и, наконец, указываем точку монтирования как / mnt / ram.

В третьей команде с поддержкой sudo мы меняем владельца каталога / mnt / ram (теперь наш RAM-диск, наша точка монтирования ramfs) на текущего пользователя и собственную группу текущего пользователя, дважды используя команду whoami. Вы можете изменить это на конкретную и / или конкретную группу, которая будет использовать ramdrive, или на более широкую группу, если больше пользователей будут использовать ramdrive.

После этого мы завершаем нашу условную команду if .. fi и выполняем последний вызов для монтирования с помощью grep for ram, чтобы убедиться, что сценарий сообщает, что уже было смонтировано с точки зрения ОЗУ, или что было смонтировано только что в качестве скрипт выполнен. Это удобная / быстрая проверка успешности выполнения сценария.

Наш вторичный сценарий, umount_ram.sh, размонтирует диск RAM с точкой монтирования / mnt / ram, то есть диск ramfs, который мы только что создали. ПРЕДУПРЕЖДЕНИЕ: выполнение этого немедленного сброса / удаления всех данных, хранящихся в энергозависимой памяти, и повторное подключение диска RAMFS не вернет этого; он просто создаст новый, но пустой RAM-диск. Пожалуйста, имейте в виду!

Подведение итогов

В этой статье мы обсудили диски RAM / ramfs (одно и то же) и экземпляры / распределения tmpfs. Затем мы создали диск ramfs объемом 1 ГБ в / mnt / ram, используя небольшой скрипт для монтирования или RAM-диска.

Если вы хотите продолжить чтение по Linux, ознакомьтесь с нашими статьями «Запись экрана в Linux с помощью SimpleScreenRecorder» или «Биты, байты и двоичные данные» или «От 0 до F: шестнадцатеричные»!

У меня есть машина с 62 ГБ ОЗУ и транк, который составляет всего 7 ГБ, поэтому я решил создать RAM-диск и скомпилировать его. Я не эксперт по Linux. Я нашел в интернете инструкции по созданию RAM-диска:

но я изменил 8192 на 16777216 в попытке выделить 16 ГБ оперативной памяти.

Я получил следующую ошибку:

В этот момент меня напугали и отпустили.

но du на /dev дает 804K .

Это проблема? Могу ли я преодолеть этот /dev размер?

Ты пробовал tmpfs? Это файловая система в оперативной памяти, нет необходимости в ext2. mount -o size=16G -t tmpfs none /mnt/tmpfs Это сработало! Спасибо! Но пока что не так много ускорения: я думаю, что инструменты, которые я использую для сборки, все еще используют обычный диск. Я положу больше материала на диск памяти. Размещение самих инструментов на виртуальном диске не должно иметь большого значения, так как ядро все равно их кеширует в ram. @goldilocks Это неподтвержденная информация, но при компиляции наших Java-проектов с помощью Maven при использовании виртуального диска происходит значительное ускорение. Я думаю, однако, что это больше из-за времени поиска, чем время чтения. / dev / shm, фактически / run / shm , можно использовать; это почти всегда там.

Лучший способ создать RAM-диск в Linux - это tmpfs. Это файловая система, живущая в ram, поэтому нет необходимости в ext2. Вы можете создать tmpfs размером 16 Гб с помощью:

в моей системе, где ничего нет в / mnt, он говорит: ls: не может получить доступ к / mnt / tmpfs: такого монтирования файла или каталога: точка монтирования / mnt / tmpfs не существует. Это то, что беспокоиться? Если я просто использую mkdir / mnt / tmpfs, то это побеждает цель (создавая tmpfs на обычном диске - пожалуйста, не пламя, я новичок здесь). Вам нужна точка монтирования (каталог) в качестве цели, поэтому после того, как вы создали этот каталог (вы можете использовать любой каталог, существующее содержимое будет затенено), вы можете смонтировать его с помощью команды из ответа. tmpfs может использовать своп, который вам, вероятно, не нужен на чистом RAM-диске. @RomanSusi tmpfs - это тип файла (передается после -t). «none» - это устройство поддержки («диск»), которое не существует для tmpfs Возможно, стоит отметить, что указание размера не является обязательным. По умолчанию используется половина ОЗУ. Нет никаких дополнительных затрат на указание большего размера, все, что он делает, это устанавливает ограничение, чтобы защитить себя от случайного использования всей вашей оперативной памяти и уничтожения системы.

Linux очень эффективно использует оперативную память. Нет ничего удивительного в том, что вы видите небольшое ускорение tmpfs . Самыми большими частями для чтения в память (и, следовательно, способными замедлить процесс) являются инструменты (компилятор, ассемблер, компоновщик), и если make долго они будут загружены в память при запуске и никогда не покинут ее. Осталось только чтение в источнике (запись результатов не замедлит вас, если только не будет сильно ограничена память). Опять же, заголовочные файлы comon останутся рядом, только источник пользователя потребует чтения. И это вряд ли будет больше, чем несколько мегабайт. Создание большого RAM-диска (или даже его интенсивное использование tmpfs ) может очень сильно замедлить работу (из-за ограничения памяти сборки файлы на RAM-диске или tmpfs не могут этого сделать использоваться непосредственно оттуда).

Они находятся в оперативной памяти, но не в формате, который можно использовать напрямую. В самом деле! Как так? (Прошу прощения за мою медлительность.) @Kazark, для обработки исполняемых файлов в памяти используются специальные структуры данных. Поскольку RAM-диски tmpfs не используются для хранения исполняемых файлов (RAM-диски являются пережитком старых добрых времен мучительно медленных дискет и т. Д., tmpfs Для жестких временных данных), никто не посчитал достаточно важным добавить необходимые уродливые хаки. Я попытался запустить мой код rails из файловой системы tmpfs (RAM), и я не увидел никакой разницы вообще. Я действительно надеялся на заметную разницу, но был разочарован тем, насколько классным является Linux.

Проблема заключается в том, что максимальный размер виртуального диска, в частности размер памяти, к которому можно получить доступ через драйвер виртуального диска, настраивается во время компиляции, может быть перезаписан во время загрузки, но остается фиксированным после загрузки ядра в память. Значение по умолчанию, вероятно, измеряется в мегабайтах. Если я правильно помню, память для RAM-диска зарезервирована прямо при загрузке драйвера, все RAM-диски имеют одинаковый размер, и по умолчанию существует около 16 RAM-дисков. Так что даже вы не хотите размер виртуального диска 16G :-)

Как указано в другом ответе, tmpfs - это то, что вы хотите использовать. Кроме того, вы не выиграете много, имея всю свою ОС в ramdisk / tmpfs. Просто скопируйте ваш builddir в tmpfs и выполните сборку. Возможно, вам придется убедиться, что все временные результаты также записаны в место, которое находится в tmpfs.

Они на самом деле не используют память, пока вы не напишите им. Ограничение времени загрузки - это только предел. Даже после заполнения вы можете освободить память с помощью blockdev --flushbufs . @psusi: можете ли вы дать нам больше информации об этом? Я могу только найти утверждения, в которых упоминается, что однажды заявленная память RAM-диска никогда не восстанавливается, например, Documentation/blockdev/ramdisk.txt в исходных текстах ядра. И на мой ответ: в этом файле также говорится, что виртуальный диск увеличивается по мере использования памяти, поэтому он распределяется не все сразу. Какого рода информация? Вы запускаете команду, и она освобождает оперативную память, если вы все равно не смонтировали ее. Откуда вы знаете, что команда делает то, что вы говорите, она делает? Его man-страница не подтверждает это, и можно понять, что документация в дереве исходных текстов ядра противоречит вашей информации.

Чтобы создать большой RAM-диск после загрузки, без каких-либо проблем с параметрами ядра, это похоже на работу. Используйте tmpfs, создайте файл, смонтируйте его через цикл и смонтируйте его через файловую систему:

Вероятно, небольшая потеря производительности проходит через несколько разных слоев . но, по крайней мере, это работает.

Помимо tmpfs и ramfs еще один вариант является /dev/ram0 блочным устройством. В последних версиях Ubuntu это устройство не существует по умолчанию, но его можно создать с помощью modprobe brd .

Этот подход более предсказуем, поскольку он создает настоящую ext4 файловую систему и никогда не превышает заданный вами предел. Но это требует больше шагов для настройки и использует ОЗУ менее эффективно.

Использование модуля ядра brd (/ dev / ram0)

Чтобы создать и инициализировать 4 ГБ ОЗУ:

rd_nr Параметр определяет , сколько дисков RAM для создания (по умолчанию он создает 16, т.е. /dev/ram0 через /dev/ram15 ). rd_size Параметр размер в килобайтах . $(( . )) Синтаксис позволяет выполнять арифметические действия в оболочке.

Чтобы освободить RAM-диск, размонтируйте его и удалите brd модуль ядра:

Создание блочного устройства внутри ramfs

Кроме того, вы можете создать блочное устройство внутри ramfs :

Команда truncate создает пустой файл заданного размера, так что он инициализируется (то есть потребляет память) по требованию.

Чтобы освободить RAM-диск, размонтируйте его и удалите образ диска:

Сравнение с tmpfs и ramfs

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

tmpfs может поменяться на диск. Это более эффективно, но могут быть случаи, когда вам нужен чистый RAM-диск:

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

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

df Утилита не сообщает использование пространства:

Параметр ограничения размера отсутствует. Если вы добавите слишком много в виртуальный диск, ваша система будет зависать.

Разреженные файлы могут стать разрозненными, когда вы меньше всего этого ожидаете. Этим утром я скопировал образ виртуальной машины ( ramfs 150 ГБ, но 49 ГБ на диске) в (у меня 128 ГБ ОЗУ). Это сработало. Но когда я скопировал из пункта ramfs назначения, моя система перестала отвечать на запросы. cp Утилита , по- видимому заполнены отверстия на чтение , но не писать.

И то, tmpfs и другое ramfs может вести себя иначе, чем настоящая ext4 файловая система. Создание блочного устройства в ОЗУ и его инициализация ext4 позволяют избежать этого.

ОП объем оперативной памяти выражается в МБ. Так что все, что вам нужно для этого - это 16384. И тогда, вуаля, вы будете в бизнесе.

Нет. «Если fs-size не имеет суффикса, он интерпретируется как степень двух килобайт». - мужчина mkfs.ext2

Вы можете смонтировать ramfs файловую систему, скопировать в нее свой проект и работать оттуда. Это гарантирует, что ваши входные файлы загружены в ОЗУ, и они не будут перечитываться с гораздо более медленного диска. Однако, как вы обнаружили, это, как правило, не полезная стратегия. Вы уже получаете точно такую же выгоду.

Ramfs - это очень простая файловая система, которая экспортирует механизмы кэширования диска Linux (кеш страниц и кэш-память) в виде динамически изменяемой файловой системы на основе ОЗУ.

Вы уже можете доверять, что ваши входные файлы кэшируются в ОЗУ, при первом чтении. Ваши выходные файлы также кэшируются, так что вы не ждете, пока они будут записаны на диск.

Не существует искусственного ограничения на объем кеширования, продолжительность его кеширования и т. Д. Кэши начинают сбрасываться только после заполнения ОЗУ. Какой кеш удаляется первым, выбирают ужасно разработанные алгоритмы. Первое приближение, мы описываем это как Наименее недавно использованный. См. Какие алгоритмы замены страниц используются в ядре Linux для кеширования файлов ОС?

Обратите внимание, что ваш текстовый редактор будет явно fsync() сохранять файлы на диск.

Если вы запускаете тесты программы, которая включает в себя fsync() , их запуск в файловой системе ramfs может ускорить их. Другая стратегия - попытаться отключить fsync() с помощью eatmydata / nosync.so .

Некоторые другие операционные системы могут иметь определенные ограничения, которые можно обойти с помощью виртуального диска. С одной стороны, отсутствие какого- либо кэширования файлов является причиной того, что ram-диски были популярны в DOS .

TMPFS

tmpfs работает так же, как ramfs , за исключением того, что он может использовать пространство подкачки, если у вас есть. Т.е., если вам нужна оперативная память для чего-то другого, алгоритмы наименьшего числа недавно использовавшихся ресурсов могут выбирать блоки данных из tmpfs и выгружать их на диск.

Большинство людей придерживаются tmpfs , потому что это также позволяет вам ограничить общий размер, и показывает пространство, используемое правильно, например, в df команде. Я не уверен, почему эта разница существует. Ограничение размера tmpfs защищает вас от случайного заполнения всей оперативной памяти и, в основном, от гибели вашей системы. По умолчанию используется половина вашей оперативной памяти.

Другие причины, почему записи могут замедляться

Выше приведено упрощение с учетом вашего случая. Записи в файлы в вашем случае не должны ждать диска. Однако есть несколько случаев, когда это делается. См. Отличный пост в блоге. Почему буферизованные записи иногда замирают . Самым удивительным случаем является недавнее изменение Linux под названием «стабильная запись страницы».

Введение в tmpfs (история)

Существуют 3 реализации технологии диска в оперативной памяти. В интернете я наткнулся на очень большое количество статей, в которых путаются местами эти три разные, но похожие технологии. Для того чтобы не возникало этой путаницы, я в статье буду применять слово рамдиск ( по-русски ) в качестве общего названия технологии используемой в linux. В статье я буду использовать дистрибутив Debian для приведения примеров, но также постараюсь обозначить отличия технологии в других дистрибутивах.

Всего ступеней эволюции рамдиска было три. Все началось с технологии ramdisk. Аналогичное именование используется и по сей день в ОС Windows. В далеком 1995 году (может и раньше) в ядро linux (вроде еще в версии до 2.0) была добавлена возможность использовать физическую память как блочное устройство. Интересно, в те времена действительно у кого-то было столько памяти, что в ней хранили данные. ) После доработки технологии ramdisk, в ядро была добавлена поддержка следующей более продвинутой технологии рамдиска под названием ramfs (приблизительных дат, когда это произошло, я не нашел), которая устранила некоторые недостатки рамдиска в ramdisk виде. И последним шагом стало появление в ядре linux поддержки tmpfs. Которая, кстати, ранее именовалась как shmfs (shared memory filesystems). Давайте от младшего к старшему рассмотрим каждую технологию.

Особенности ramdisk.

Рамдиск в виде ramdisk в зародыше представлял собой блочное устройство в каталоге /dev. Точно так же как и любое другое блочное устройство (жесткий диск /dev/sda, флоппи /dev/fd. ):

Недостатки ramdisk:

Так как ramdisk работает как обычное блочное устройство с файловой системой, оно точно так же использует возможности кэширования данных записываемых на файловую систему и считываемых оттуда. Из этого можно сделать вывод, что данный вид рамдиска использует дополнительные ресурсы памяти и CPU для управления файловой системой, кэшем.
Имея фиксированный размер, ramdisk не может использовать swap раздел, если не хватает свободной физической памяти.
Стоит так же отметить, что изменить размер ramdisk не так-то просто. (это относится к рамдиску, интегрированному в ядро. Не модулем)

Чтобы убедиться, что Ваша система поддерживает рамдиск ramdisk, необходимом проверить следующие параметры для запущенного ядра:

Что мы видим в данных параметрах? CONFIG_BLK_DEV_RAM=m нам говорит, что устройство ramdisk поддерживается ядром в виде модуля. Если бы вместо m стояла y, то это бы означало, что ramdisk интегрирован в ядро и при загрузке в каталоге /dev будет создано 16 устройств (CONFIG_BLK_DEV_RAM_COUNT=16). Например, RedHad дистрибутивы (Fedora, CentOS, AltLinux. ) так и поступают:

но в Debian дистрибутивах этого не замечено. Далее, CONFIG_BLK_DEV_RAM_SIZE=8192 указывает нам, что размер одного устройства будет равен 8192 Кб. Необходимо понимать, что пока данные диски не отформатированы и не примонтированы и не заполнены - они не занимают место в оперативной памяти.

Работа с ramdisk.

Как видно, у модуля имеются некоторые параметры. Давайте попробуем ими воспользоваться:

Итак, создали на диске файловую систему ext2. Память опять почти не изменилась. Хм. Почти все источники в интернете утверждают, что после форматирования диска, кусок размером с объем раздела отрезается от свободного пространства памяти. (Видимо, в последних версиях ядра данный модуль переделан и более так себя не ведет.) Примонтировали. Память как был свободна, так и осталась. Далее.

Итак, диск у нас наполнился файлом на весь доступный объем. Как видно, памяти отрезано по размеру диска. Вот тут, я бы хотел, кое-что прокомментировать:

Примечание (или что показывает free в столбце used). used=shared+buffers+cached+память_используемая_работающими_программами_в_пользовательском_режиме. При этом, память используемую под buffers+cached можно считать свободной, т.к. эта память будет отдана приложениям, как только она понадобится. Так же стоит отметить, что данную занятую память вы не увидите не в команде top, ни htop, ни в других, т.к. занята она ядром.

Еще пару экспериментов:

Итак, грохнули файл на ramdisk - память как была занята, так и осталась. Отмонтировали /dev/ram0 - память как была занята, так и осталась. Вывод - ядро не возвращает освобожденное на диске место. Перезагружаем Linux и еще пару экспериментов.

Как говориться, за что боролись, на то и напоролись ) Следующий нюанс при работе с ramdisk, который я бы хотел затронуть - это как изменить размер ramdisk. С учетом примеров выше, становится понятно, что подключив нужный модуль в ядро с помощью нужной команды (insmod) и подходящих параметров (rd_size), можно изменить размер без перезагрузки. Но как же нам поступить в случае, если ramdisk интегрирован в ядро? В данном случае имеется два пути (по крайней мере, я больше не знаю. ):

Указать в параметрах загрузки ядра значение в виде ramdisk=xxxK. (В Debian, например, это делается в /etc/default/grub. В RedHat - это (вроде) /etc/sysconfig/grub, но могу ошибаться)
Есть более серьезный путь - пересобрать ядро, изменив параметр CONFIG_BLK_DEV_RAM_SIZE на необходимое значение.

Итак подведем маленький итог ramdisk, допустим, не дочитав статью Вам ужас как хочется использовать данный рамдиск в работе, вам необходимо:

Подключить модуля ядра (rd.ko или brd.ko), если ramdisk собран в ядре в модульном виде.
Создать файловую систему на рамдиске
Примонтировать рамдиск
Пользоваться
Если есть желание, чтобы данный диск монтировался при загрузке, то необходимо создать соответствующий скрипт с учетом вышеприведенных шагов и добавить с какой-нибудь загрузочный файл (например, /etc/rc.local).

Особенности рамдиска ramfs.

Ramfs это более грамотная и усовершенствованная реализация технологии рамдиск. Особенностью ее является то, что нет необходимости создавать специальное блочное устройство и форматировать его. В man mount так и сказано: "Mount options for ramfs: Ramfs is a memory based filesystem. Mount it and you have it. Unmount it and it is gone. Present since Linux 2.3.99pre4. There are no mount options." То есть, остается просто смонтировать файловую систему ramfs и она у Вас будет. При этом, использованная, но уже не используемая память теперь умеет освобождаться. Стоит отметить, что данный рамдиск умеет монтироваться из /etc/fstab.

Недостатки ramfs.

Но ramfs не осталось без недостатков. Фактически, при монтировании данного типа файловой системы не представляется возможным указать предельный размер. То есть, существует параметр задающий размер диска, но этот параметр задает размер куска, который отрубается от оперативной памяти сразу при монтировании (Скажем так, стартовый размер.). При этом, ограничить рост занимаемых данных более стартового размера - невозможно. Этот недостаток требует от приложений, которые будут писать в что-либо ramfs, контроля размера записываемых данных.

Чтобы убедится, что Ваша система поддерживает рамдиск ramfs, можно выполнить следующее:

Работа с ramfs

Давайте попробуем препарировать ramfs.

Давайте попробуем разобраться в листинге. Как видно, при монтировании рамдиска ramfs размер оперативной памяти не изменился. Далее, записали 200Мб в примонтированный раздел. Интересный нюанс: ramfs использует область памяти, используемую в качестве cached. При этом, нужно понимать, что память забранная под cached ramfs'ом не будет возвращена приложениям при запросе. Далее, удаляем созданные 200Мб и ядро освобождает выданную ранее память. Ну и проверяем последнее утверждение, что рамдиск не ограничен по росту и видим как ядро в шоке )

Особенности tmpfs в linux.

На текущий момент, tmpfs это самый совершенный рамдиск. Tmpfs ранее именовалась как shmfs (shared memory filesystem). Данная файловая система учла все достоинства прошлых рамдисков и включила исправленные недостатки:

Раздел tmpfs можно ограничить по размеру,
tmpfs при нехватке основной памяти научился использовать swap раздел.
Если размер рамдиска не указан явно, то диск монтируется в половину размера ОЗУ.

В современных дистрибутивах tmpfs используется довольно активно, например он используется udev'ом для обслуживания устройств в каталоге /dev, так же часто в виде tmpfs монтируются каталоги /tmp или /var/tmp, содержимое которых нет необходимости хранить долговременно. Проверить, поддерживает ли Ваша система tmpfs можно следующей командой:

Tmpfs обладает рядом специфичных параметров, которые возможно указать при монтировании, давайте разберем их:

size=ххх - Задает максимальный размер монтируемого tmpfs. Указывается в битах (или в процентах) и при монтировании округляется до целых страниц памяти. Как я уже сказал, если не задать данный параметр, то рамдиск будет примонтирован с размером, равным половине физической памяти.
nr_blocks=xxx - Также, задает размер tmpfs, но в блоках PAGE_CACHE_SIZE. (частно сказать, я не понял что еть данный параметр. )
nr_inodes=xxx - Задает максимальное число inod. По-умолчанию, данный параметр имеет значение, равное половине количества физических страниц ОЗУ (если используется ядро hightmem, то половина страниц lowmem-памяти). Какой порядок цифр выделения inod при определенном size? Я не смог найти какой-либо статистической информации, но могу дать следующий совет: если планируется записывать большое количество мелких файлов на раздел tmpfs, то рекомендуется указать значение, заведомо большее, чем количество записываемых файлов.
- Примечание: Все вышеуказанные параметры могут указываться с суффиксами k,m,g или Ki, Mi, Gi и могут изменяться "налету" с командой mount и опцией remount.
Работа с tmpfs

Ну и несколько команд, показывающих использование tmpfs в Linux:

Давайте попробуем разобраться, что мы тут увидели? Смотрим, что исходно у нас памяти used 20 и cached 4 Мб. Монтируем tmpfs размером 100Мб. Объем памяти почти не изменился. Это подтверждает, что система не отрезает сразу целый кусок, равный диску. Далее, наполняем файл testfull (командой dd) на примонтированном разделе до предельного размера и видим, что он после наполнения уперся в объем диска и наполнение останавливается. free -m показывает, что заполнена память из области cached. Удаляем созданный на tmpfs файл и место освобождается. Далее, снова до предела наполняем примонтированный раздел. Пытаемся изменить размер tmpfs раздела до 150Мб без размонтирования. и командой df наблюдаем, что на разделе прибавилось свободных 50Мб. Класс! При этом, все данные, которые были до перемонтирования на диске, остались неизменными. Заполняем оставшееся место файлом testfull2. Диск наполнен. Система вполне продолжает свою работоспособность )

Еще один эксперимент. Размонтируем раздел tmpfs - память освободилась. Далее, предположим, что какие-то пользовательские приложения заняли 200 с лишним Мб памяти (219Мб). Примонтируем диск, заведомо больше, чем доступная свободная память (250М). Наполняем диск до предела и видим, что:
1. скорость записи упала до 28,5 Мб
2. swap наполнился данными, что говорит нам, что записанные в tmpfs данные писались в swap
Стоит так же отметить, что повредить систему мне удалось лишь заполнив рамдиск tmpfs, задав размер tmpfs более чем сумма оперативной памяти и swap.

Пример использования tmpfs для сервера печати в домене AD

Вот живой пример использования tmpfs для ускорения работы очереди печати SAMBA+CUPS. Создаем tmpfs раздел /spooler при загрузке системы, в который размещаем спулер очереди печати демонов CUPS и SAMBA:

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

Безопасность ramdisk, ramfs, tmpfs

Особое внимание стоит уделить безопасности рамдиска ramfs, т.к. данный вид рамдиска никак не ограничивает рост занимаемой ОЗУ. Для того чтобы защитить ваш Linux от краха, необходимо ограничить права доступа на запись в примонтированный раздел. Для этого, в tmpfs имеются параметры монтирования mode=, uid= и gid=nnn. Для ramfs это реализуется посредством задания прав доступа на точку монтирования. Для ramdisk используются стандартные параметры монтирования любой файловой системы с указанием прав и ID групп и пользователя. Стоит понимать, что кроме специфических параметров монтирования рамдиск имеются и стандартные опции, такие как noexec, nosuid и др., ограничивающие возможности неправомерного использования раздела.

Tips & Tricks tmpfs

Bind-монтирование для куска файловой системы

Про bind mounting можно почитать в ссылках в конце статьи. Далее, интересный пример с сайта ibm.com: вы монтируете tmpfs к /dev/shm, его "традиционной" точке, но одновременно хотите использовать tmpfs для /tmp. Вместо монтирования еще одной tmpfs к /tmp (что возможно), вы решаете объединить /tmp с /dev/shm. Но, bind mount /dev/shm к /tmp нужно сделать так, чтобы каталоги из /dev/shm не были видны в /tmp. Как это сделать? Пример:

В этом примере сначала создается каталог /dev/shm/tmp и назначаются права доступа 1777 (обычные для /tmp). Далее можно монтировать только отдельный /dev/shm/tmp. После этого файл /tmp/foo будет дополнительно виден как /dev/shm/tmp/foo, но файл /dev/shm/bar в каталоге /tmp отображен не будет.

Swap без изменений в структуре файловой системы

Если Вам необходимо разово расширить объем виртуальной памяти за счет своп раздела, при этом нет возможности изменить таблицу разделов, есть возможность добавить кусок свопа в виде файла. Это может понадобиться, например, для сборки крупного пакета. Пример данной конфигурации:

Стоит учитывать, что на linux архитектуре x86 возможно использовать размер свопа не более 2 Гб. Но этих файлов можно подключать несколько.

Давайте подведем краткий итог вышеизложенного. Для большинства задач наиболее подходящим является реализация tmpfs, как обладающая наибольшим функционалом и отсутствием недостатков. Ниже маленькая сводная таблица:

Читайте также: