Хабр Geektimes Тостер Мой круг Фрилансим

Мегапосты: Вернуть экзаменыКейсы с SAP HANAГайд для безопасника

Публикации

Пользователи

Хабы

Компании

Песочница

Войти Регистрация

aokoroko 23 марта 2015 в 12:22

Файловая система Linux полностью на tmpfs — скорость без компромиссов

Высокая производительность

Из песочницы

Предыстория

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

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

Ниже я опишу такой способ, который был с успехом опробован. Для опытов был взят самый заслуженный дистрибутив Linux — Debian.

Я использовал сетевую установку, с самого минимального набора:
http://ftp.nl.debian.org/debian/dists/unstable/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
http://ftp.nl.debian.org/debian/dists/unstable/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz

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

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

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

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

mkdir /ramboottmp
mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} /ramboottmp
mount -t tmpfs -o size=100% none ${rootmnt}
cd ${rootmnt}
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:

Теги:

Linux

скорость работы

tmpfs

рамдиск

latency

iops

fio

Добавить метки

Пометьте публикацию своими метками
Метки лучше разделять запятой. Например: программирование, алгоритмы

Сохранить

Яндекс.ДиректСодействие в подборе финансовых услуг/организацийЛиквидация склада RENAULT!krasnodar-renault.ru  Скрыть объявлениеКупите Б/У Сервер в [РФ]ittelo.ru  Скрыть объявлениеNissan Qashqai за 250 рублей в деньnissan.keyauto.ru  Скрыть объявление

Тест: что ты знаешь о цифровых сервисах

Проверить

Читают сейчас

Хрупкий кабель дисплея MacBook Pro: очередная ловушка, в которую загнали себя инженеры Apple
25,4k 111

Android Q поможет жестко «привязать» мобильный телефон к оператору связи
4,9k 14

Приглашая опытного разработчика, вы не покупаете, а продаёте
15,5k 44

Николай Дуров на 90% закончил разработку платформы Telegram Open Network
9,2k 9

Backblaze опубликовала статистику надёжности HDD за 2018 год
4,6k 10

Ослабляем гайки в правилах Хабра
29,3k 598

+65

654

93,5k

164

Выберите рекомендации для отправки автору:

Указан только блог Орфографические ошибки Пунктуационные ошибки Отступы Текст-простыня Короткие предложения Смайлики Много форматирования Картинки Ссылки Оформление кода Рекламный характер

Отправить

Нарушение
Опишите суть нарушения

Отправить

19,0

Карма

0,0

Рейтинг

3

Подписчики

Артур Фирюлин aokoroko

Пользователь

Поделиться публикацией

Похожие публикации

7 марта 2012 в 21:22
Влияние частоты процессора и количества его ядер на скорость работы антивирусных средств

+19 30,9k 69 71

9 июля 2010 в 06:06
Сравнительное тестирование скорости работы software RAID'ов. Linux vs FreeBSD(mdadm vs gmirror)

+46 13,1k 34 57

17 июня 2009 в 16:28
Opera — скорость работы в linux

+26 2,4k 4 178

Вакансии

Администратор linux \ веб серверов

COSMOS Москва

от 120000 до 150000

Системный администратор Linux (удаленно)

Евробайт Возможна удаленная работа

от 35000 до 43000

Системный администратор Linux (системная интеграция)

ITM Холдинг Екатеринбург

от 65000

Ведущий системный программист Linux

Т-Платформы Москва

от 100000 до 200000

Ведущий системный администратор Linux

Мамба Москва

от 150000 до 190000

Все вакансии

Комментарии 164

lolipop 23 марта 2015 в 12:29

+3

habrahabr.ru/post/164147/
вы можете возразить, что появятся оверхед от squashfs, но по факту это не заметно.

merlin-vrn 23 марта 2015 в 12:42

+4

… потому, что оверхед от squashfs обычно пересиливается ускорением за счёт уменьшения объёма пересылаемых данных

saboteur_kiev 23 марта 2015 в 12:31

+2

Как вы решаете проблему, если нужно что-то доустановить или изменить конфигурацию?
Каждый раз целиком пересоздаете ram.tar.gz?

Я давно хотел сделать что-то подобное для Windows и SSD, чтобы система свои постоянные обращения к диску делала в рамдрайв, и только пару раз в день скидывала изменения на SSD. И быстро и срок службы продлевается. Но эту задачу решить не удалось. Инструменты типа рамдрайв скидывают только полный дамп на диск…

Evengard 23 марта 2015 в 12:38

+1

Я тут так подумал, что можно попробовать таки хранить в полноценном разделе всё, из него всё и копировать в tmpfs, и заскриптить при помощи inotify сбрасывание обратно, но там достаточно много скорее всего особенностей.

aokoroko 23 марта 2015 в 13:43

0

У меня, кроме производительности, была еще цель создать неубиваемую систему, поэтому изменение архива никак не автоматизировано, оно делается редко, вручную, сразу после перезагрузки, вносятся необходимые изменения и делается новый архив. Такие предосторожности, чтобы не доустановить что-нибудь плохое. Но это если накопилось много претензий и хочется переделать. А так вообще в дебиане очень просто что-то доустановить из репозитория. Можно неделю, месяц работать не перезагружая систему, делать с ней все, что заблагорассудится, ставить софт и т. д. Единственно, конечно, объем установленной RAM ограничивает.

BupycNet 23 марта 2015 в 16:17

+2

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

И там гибкость была в том, что можно было создать несколько squashfs архивов с различными конфигурациями, и грузить их если что либо необходимо. Можно было на 2х гигах оперативы загружать к примеру либо образ для работы с графикой, а потом быстро переключаться на образ для игр, или например образ для разработки с различными IDE.

aokoroko 23 марта 2015 в 17:33

0

Угу, я слежу за puppyrus, он развивается, вот свежий, построенный на Арче: PuppyRus-A

ivlis 23 марта 2015 в 21:04

0

А обновления как? Каждый раз при загрузке системы?

aokoroko 23 марта 2015 в 21:54

0

Увы, да. С быстрым каналом в Интернет большой проблемы в этом нет. Если же машина будет использоваться без сети (как домашний кинотеатр или печатная машинка), то и обновления особо не нужны…

pcmaniac 24 марта 2015 в 11:41

+1

У меня три года рабочие станции жили на EWF — как раз то что вам нужно: habrahabr.ru/company/pt/blog/155135/

SunX 24 марта 2015 в 13:13

0

Что-то очень похожее на LVM

pcmaniac 24 марта 2015 в 20:05

+1

Там ФС живёт на диске, изменения кэшируются в оперативке и при перезагрузке херятся. Если нужно внести изменения в ФС, просто пинаешь специальный батник и тогда при перезагрузке или выключении машины кэш сбрасывается на диск. Очень помогало от криворуких пользователей и вирусняков. Все проблемы решались перезагрузкой. Одно неудобство было только при установке тяжёлого софта. Например на машине с 512Гб оперативки не получалось вкатать OpenOffice т.к. он при установке записывал на диск больше данных, чем умещалось в оперативке. Самым активным юзерам делали апгрейды до 1-2Гб, но 70% народу сидело на 512Мб вполне комфортно.

Meklon 23 марта 2015 в 12:53

+6

Очень круто. Как раз памяти много. Вы можете пояснить как данные сохраняются? например, я обновил софт или новый поставил. Я упустил этот момент. Плюс home раздел на ssd и в tmpfs не заливается, наскрлько я понимаю.

GreyCat 23 марта 2015 в 13:23

+13

Да никак не делается. Автор сначала обругал squashfs (он якобы медленный — но скромно умолчав о том, сколько занимает зачитывание и распаковка всего тарболла разом с носителя в tmpfs), потом второй раз обругал squashfs (якобы там сложная многослойная система монтирования) — но в предложенном варианте все эти «проблемы» с persistency просто игнорируются — всё живет до тех пор, пока есть питание и жива система.

aokoroko 23 марта 2015 в 13:54

+1

Да, согласен, у меня нет никакого persistency, зато можно безопасно экспериментировать, не боясь убить систему. Это, можно так сказать, не баг, а фича, что после перезагрузки происходит фактически откат ОС на эталонный образ — так было задумано ради безопасности.
Тарболл у меня вышел около 600 Мб, зачитывание и распаковка его происходит быстро. Да и не очень это критично делать раз в день…

GreyCat 23 марта 2015 в 14:05

+2

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

encyclopedist 23 марта 2015 в 14:20

+3

Да ещё и после перезагрузки автор получает систему без обновлений безопасности.

aokoroko 23 марта 2015 в 14:25

0

А вот это спасибо, что заметили. Применительно к Debian, видимо, стоит сразу после перезарузки исполнять apt-get upgrade?

SunX 23 марта 2015 в 15:41

0

apt-get update перед этим не забудьте.

aokoroko 23 марта 2015 в 15:59

+1

Да-да, конечно, спасибо, я забыл упомянуть, это необходимо.

encyclopedist 26 марта 2015 в 20:08

0

Ядро обновить так просто не получится.

miwa 26 марта 2015 в 21:17

0

Уже много лет получается.

encyclopedist 26 марта 2015 в 21:20

+1

Возможно я делаю что-то не так, но у меня после apt-get upgrade нужно перезагрузиться, чтобы запустить новое ядро.

Да, я слышал про kexec, но мы тут обсуждаем apt-get upgrade.

aokoroko 23 марта 2015 в 14:24

0

Но ведь произвести несанкционированные изменения файлов внутри архива на рид-онли носителе практически невозможно, в отличие от файловой системы на обычном носителе. В течение некоторого времени после загрузки мы можем быть уверены в «чистоте» системы. Я ошибаюсь?

GreyCat 23 марта 2015 в 14:33

+3

Мне очень нравятся «практически невозможно» и «в течение некоторого времени мы может быть уверены» :) Это как «немножко беременна».

Если у вас только не аппаратно защищенный носитель (а вы говорили о флешках, HDD и SSD), имея в системе рута, никто не запретит malware замонтировать этот носитель в read-write, распаковать этот самый архив, сделать изменения и перепаковать его вновь. Не говоря уже о том, что ядро у вас как грузилось с этого носителя, так и грузится. Руткиты для фактически любых ядер сейчас доступны каждому.

«Некоторое время», при условии наличия в сети активного атакующего со свежим remote root exploit'ом, будет стремиться к нулю. За примерами даже далеко ходить не надо — DHCP-сервер злоумышленника с ответами специального вида + Shellshock + достаточно старый dhclient / dhcpcd = исполнение произвольного кода из под root еще на этапе загрузки системы и получения IP-адреса.

aokoroko 23 марта 2015 в 14:50

0

Упомянутый тарболл хранится также на CD-R и на флешках, контроллер которых перепрограммирован и представляется CD диском, то есть аппаратно read-only. Если на read-write носителях он будет перепакован, то я это замечу по изменению его контрольных сумм?

GreyCat 23 марта 2015 в 15:17

0

Если у вас есть внешняя сущность, с которой сравнивать (контрольные ли суммы или сами файлы) и сам процесс сравнения — то, разумеется, заметите. Если это не внешняя сущность, то никто не мешает malware модифицировать процесс сравнения так, чтобы он показывал, что все хорошо, когда на деле руткит будет внедрен.

Впрочем, все это уже относится к области работы IDSов и антивирусов — там уже до нас с вами накоплены многие годы опыта и придумана масса вещей. И в этом месте «обычный компьютер + IDS или антивирус» как бы не будет толком ничем отличаться от «компьютер с tmpfs root + IDS или антивирус».

aokoroko 23 марта 2015 в 13:48

–3

Когда я ставил Debian с нуля, поставил ВСЁ в один раздел. Т. е. /home тоже архивируется в образ для рам-загрузки.
Обновления да, не сохраняются. Данные, с которыми работаю, сохраняю на те носители, что есть — флешки, облака, HDD есть в компе не один…

Meklon 23 марта 2015 в 13:13

+3

Кстати, заодно хочу спросить — никто не знает как более агрессивно усилить кэширование? Память простаивает) стоит preload.

immaculate 23 марта 2015 в 13:53

+9

Я думаю, что все кэшируется и так максимально оптимально. Такие «вопросы» и «руководства» появляются, когда у человека мало реальных задач и много свободного времени.

Когда решаешь реальные задачи, это не имеет значения. У меня ноутбук с SSD. Я начинаю работу с того, что запускаю основные свои инструменты: консоль, Firefox, и PyCharm. Когда заканчиваю день, закрываю ноутбук и он уходит в suspend. То есть, один раз я может быть жду 1,5 секунды пока загрузится Firefox с SSD, но это терпимо, так как это и так очень небольшое время, и запускается он не чаще одного раза в две недели, а то и больше.

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

MichaelBorisov 23 марта 2015 в 16:37

0

А у вас своп-файл включен? Попробуйте отключить — нагрузка на память возрастет, снизятся затраты времени на своп. Когда на компьютере было достаточно памяти (с WinXP), я именно так и работал. Значительно повышается производительность.

pansa 24 марта 2015 в 01:58

+2

Что такое «усилить кэширование»? Где? В linux практически любое обращение к диску прозрачно кэшируется VFS'ом, выделяя под это дело всю свободную в данный момент память. Упрощенно. Так что в линуксе память не простаивает, не думайте, что вы один об этом подумали =)

Gordon01 24 марта 2015 в 04:21

0

А swap выключен?

Meklon 24 марта 2015 в 09:25

0

Включён. Его вроде некошерно отрубать совсем. Только не раздел, а файл, который растёт динамически.

Gordon01 24 марта 2015 в 09:30

0

Тогда, если хочется кошерно vm.swappines на ноль ставить.
P.S. без свапа уже лет 5, единственная проблема — некошерно.

Meklon 24 марта 2015 в 11:46

0

Хм. Попробую)

НЛО прилетело и опубликовало эту надпись здесь

omegicus 23 марта 2015 в 13:22

–11

СЦ) опиши как NTFS сделать в RAMDisk подробнее (то, что в первом абзаце)!!!)))

Goodkat 23 марта 2015 в 13:22

+2

Расскажите, как вы втиснули Windows в 16 ГБ.
Или у вас там XP?

Jeditobe 23 марта 2015 в 13:32

+1

Да, сколько у Автора было оперативки?

EndUser 23 марта 2015 в 14:05

0

Вопрос хороший. Сейчас у меня: C:\Windows\ 32GB; C:\ProgramData\ 23GB; C:\Program Files\ 12GB; C:\Program Files (x86)\ 19GB. итого 87 GB.

aokoroko 23 марта 2015 в 14:16

+2

Сразу после установки Win 8.1 x86 на диске C: было занято 2.7 Гб, после установки нужного мне софта стало занято 4 Гб. Дело в том, что использовался подготовленный дистрибутив. Нет, не скачанный где-то в сети, а сделанный самостоятельно из оригинала Microsoft без использования каких-либо программ «для урезания» (которых сейчас развелось много), а только с помощью dism и regedit.
Вот я не знаю, подскажите, не будет ли против правил написать об этом статью на Хабр? Вроде бы Microsoft не разрешает производить подобные манипуляции со своими дистрибутивами?

EndUser 23 марта 2015 в 15:21

+2

Политику MS не подскажу. Но конфигурация ОС вполне в духе Хабра. Однако, дюже любопытно, куда предусмотреть обновления (и резерв на откат), которые растут из недели в неделю. Не уж то целевая конфигурация «для школьного кабинета информатики; моей бабушке» высвобождает такие резервы по оптимизации размеров?

aokoroko 23 марта 2015 в 15:37

+1

В отличие от Linux, обновления Windows обычно требуют перезагрузки, так что Windows на рам-диске не обновить никак. Чтобы обновить, понадобится ее грузить обычным способом. Но есть удобная технология от M$ — VHD диск. Его можно грузить обычным способом для настройки, обновления и т. д. и в RAM для быстрой работы.

BupycNet 23 марта 2015 в 16:24

0

Есть очень удобная технология у linux — squashfs. Вы можете вместо tar.gz архива писать в архив squashfs. Если вам нужно обновить конфигурацию, вы можете загрузиться с примонтированным файлом squashfs и работать с ним. А потом можно загрузиться выгрузив его весь в RAM.

aokoroko 23 марта 2015 в 17:24

0

А можно squashfs примонтировать на запись?

SunX 23 марта 2015 в 17:57

0

Нет, нельзя придется как и в случае tar распаковать, поменять, запаковать. ну или изменения положить в отдельный squashfs файл

DeeZ 12 мая 2015 в 20:28

+1

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

Stalker_RED 23 марта 2015 в 15:56

0

Строго говоря Program Files — не совсем операционка. У меня стоит семерка установленная еще в 2009. Изначально занимала около 15Гб, а сейчас раздулась до примерно 25 (в основном за счет winsxs, у которго как-то туго с чисткой хлама)

aokoroko 23 марта 2015 в 16:06

+2

8 октября 2013 года вышло рекомендуемое обновление KB2852386 для Windows 7 SP1 support.microsoft.com/kb/2852386. Оно добавляет функцию очистки WinSxS в утилиту «Очистка диска»

Работает не так хорошо, как в восьмерке, но работает.

aokoroko 23 марта 2015 в 14:06

+2

У меня там Windows 8.1 и сейчас я пишу этот коммент в ней.
Вот как выглядит диск C:, который расположен в RAM:

timerbulatov 23 марта 2015 в 13:26

0

Тоже экспериментировал с системой в памяти — создавал виртуалку, жесткий диск которой полностью был в памяти — потрясно быстро работает… но столкнулся с проблемой сохранения изменений после обновления например — каждый раз экспортировать напрягало…
Кроме того — не совсем согласен с неубиваемостью — если выключат электричество или система наглухо зависнет — все изменения пропадут же?

Cheater 23 марта 2015 в 13:57

+1

Под неубиваемостью скорее всего имелась в виду возможность любую поломку вылечить ресетом. По поводу пропадания изменений: я бы не сказал, что прямо все изменения исчезают. Они пропадают ровно по тому же принципу, как и в обычной системе на hdd: то, что было в памяти — пропадёт, то, что было на hdd/nfs/samba/… — не пропадёт. Т.е. никто не мешает, например, загрузить ОС в память, как делает автор, затем примонтировать HDD или NFS шару и редактировать данные там.

aokoroko 23 марта 2015 в 14:00

0

Вы правы, если пропадет питание (UPS поможет) или зависнет наглухо (тут уже да, не поможет ничего), то пропадут изменения ОС. Но это, мне кажется, не очень страшно. Под неубиваемостью я имел в виду свойство неизменности тарболла. Если система наглухо зависнет, я нажму Reset на системнике и через минуту уже буду в неизмененной системе.

immaculate 24 марта 2015 в 08:41

–2

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

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

Мне не надо, чтобы у меня «тяжелые приложения» запускались со скоростью света. Во-первых, на SSD они и так настолько быстро запускаются, что едва замечаешь. Во-вторых, никто в реальной работе не использует карусель: запустил LibreOffice, тут же закрыл, затем Firefox, затем Gimp, затем Blender, затем Idea, все позакрывал и начал сначала.

Когда решаешь настоящие задачи, как правило, открываешь одно-два приложения, и работаешь в них. Поэтому мне вообще непонятна цель подобных извращений — не могу придумать workflow, в котором надо непрерывно открывать и закрывать тяжелые приложения.

aokoroko 26 марта 2015 в 17:18

0

По вопросу «нагухо виснет» вы отвечайте, пожалуйста, не мне, а timerbulatov. У меня такой проблемы нет и статья не о решении проблем зависания. Также она не о RAMDISK, который есть блочное устройство. Ну и закрывать приложения не обязательно. На «черти» и «извращения» ответил в другом месте.

saboteur_kiev 26 марта 2015 в 18:19

0

Скорость записи на SSD все же гораздо ниже, чем скорость записи на диск.
Я наглядно вижу, что firefox на Ramdisk живет быстрее чем на SSD. Вдобавок это как раз то, что чаще всего пишет ненужные (временные файлы) на диск. А к чувству «SSD не жалко» я только начал привыкать.

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

immaculate 26 марта 2015 в 18:30

0

У меня, например, Firefox начинает ощутимо тормозить, когда остается мало памяти (другой процесс много съел, например). Если я его скопирую в RAM-диск, то этой памяти станет еще меньше…

saboteur_kiev 27 марта 2015 в 16:18

0

А я достаточно часто открываю и закрываю Firefox. Выделить 300 мегабайт для рамдиска с firefox и far мне не кажется слишком напряжных в системах с 4гб и выше.

SunX 23 марта 2015 в 14:07

+2

На счет изменений можно посмотреть в сторону UnionFS и ее аналогов (вроде в Linux в последнее время это все встроено в mount и ядро) т.е. вы как-то раз делаете снэпшот файловой системы в удобном для Вас виде (squashfs, tar.gz, etc..) монтируете это в режиме только для чтения, а поверх монтируете то, куда попадут все изменения. И раз в N времени перепаковывать все в основной снэпшот.

sgtpep 23 марта 2015 в 14:05

+1

Спасибо за описание интересного опыта. Навело на мысли попробовать построить подобную систему на основе archboot wiki.archlinux.org/index.php/Archboot. Сам пользуюсь портативным арчом, установленном на флешке. Размещение системы в памяти радикально решило бы проблемы производительности. А персистентность можно было бы решить использованием второй флешки с обычной файловой системой.

sequence 23 марта 2015 в 14:19

+4

Использую подобное решение с tmpfs на паре production серверов.
Загрузка осуществляется с SSD, скорость старта системы (debian 7) не более 5 секунд.

Осмелюсь добавить небольшие лайфхаки:
1. В grub два выбора загрузки системы, в RAM и с Диска.
В случае необходимости обновления/модификаций системы грузимся с Диск, проводим работы.
2. Синхронизацию конфигов /etc/* можно выполнять автоматически с помощью скриптов по связке iwatch->mount Disk->unison(rsync)->umount (Физический диск у меня в нормале отмонтирован)
3. Скрипт чистки /var/{log,cache,...etc) при ребуте. Либо /var/{log,cache,...etc) отдельным разделом, чтобы система не стартовала со старыми лог/кэш файлами.
4. Внешние системы логгирования (kmsg&syslog -> remote syslog || logstash) дабы не замусоривать систему и иметь логи в случае внезапного краха системы (тьфу*3).

И ещё:

mount -t tmpfs -o size=100% none ${rootmnt}

Использовать всю память под диск, слишком оптимистично. В случае недосмотра и переполнения диска рискуем получить OOMKiller в системе. Потому запас для работы системы оставлять всё же нужно.

GreyCat 23 марта 2015 в 14:24

0

Если уж так тянет использовать tmpfs — OOM killer вообще благоразумно фактически отключать, запрещая overcommit в 0, иначе поведение системы будет совершенно непредсказуемое.

saboteur_kiev 23 марта 2015 в 14:24

+2

А мог бы автор написать подобную статью, но для Windows?

Я сейчас использую ramdisk для самых необходимых приложений (far, firefox), и собственно больше всего напрягает именно периодическое сбрасывание рамдиска на жесткий диск. Компьютер не перегружаю месяцами, но чтобы ничего не потерять сброс настроил каждые сутки. И из-за него держу рамдиск минимального размера.

Было бы прекрасно придумать варианты, как на рамдиске держать tmp/system32/config и другие папки, в которые вин все время что-то пишет. Это скорее связано даже не столько с ускорением работы, сколько с минимизацией обращения к SSD на тему записи.

aokoroko 23 марта 2015 в 14:32

+2

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

foxmuldercp 23 марта 2015 в 15:00

0

Удаляйте на здоровье, там ничего сложного нет. Тем более для схем RDP Farm/VDI, когда в системах клиентов не должно быть ничего лишнего.
Я то знаю, как это делать, а для новичков — думаю было бы интересно, а вот кейс применения — каждому свое

aokoroko 23 марта 2015 в 15:14

0

Ну действительно, тонкие клиенты, киоски… Если не запрещено это делать, то напишу. Помнится, я был в полном восторге от того, что 8.1 Pro можно уместить в 2.7 Гб.

aulandsdalen 24 марта 2015 в 08:23

0

Не запрещено, нет. По крайней мере, в ГК РФ точно сказано, что обладатель лицензии на продукт может его как угодно изменять, в РБ скорее всего так же.

jcmvbkbc 24 марта 2015 в 16:39

+1

в ГК РФ точно сказано, что обладатель лицензии на продукт может его как угодно изменять

Было сказано. Раньше. Теперь немного по-другому (ст. 1280 ГК РФ):

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

aokoroko 23 марта 2015 в 14:41

0

Хотя… если поставить 32 Гб RAM, то можно не модифицировать дистрибутив Windows. Она поместится.
Но сама технология Windows в RAM очень простая, не уверен, что наберется на статью…

saibaneko 23 марта 2015 в 15:35

0

Может тогда поделитесь ссылкой где об этом можно почитать?

berezuev 23 марта 2015 в 15:47

0

ну серьезно, гуглится же за 3 секунды: geektimes.ru/post/185172/

aokoroko 23 марта 2015 в 15:57

0

Ну вот, уже все написано, значит нужды писать еще одну статью нет.

DeeZ 12 мая 2015 в 20:42

0

berezuev, спасибо и плюсик.
aokoroko, опишите пожалуйста про пакеты, какие можно удалять и как найти нужный (как то возился с языковыми пакетами, и помню тот ужас который меня охватывал от этого не юзерфрендли способа установки\удаления)

saibaneko 23 марта 2015 в 21:48

0

Отправил в избранное. Спасибо.

aokoroko 23 марта 2015 в 15:51

0

Мне не попадалась толковая статья, где все было бы собрано в одном месте, поэтому, думаю, все же напишу. Ключевые компоненты, которые нужны, — это загрузчик grub4dos и драйвер его рамдиска firadisk. Загрузчик китайских разработчиков и про него пишут, но как-то фрагментарно и многое устарело. Официальный сайт у него grub4dos.chenall.net/
Драйвер разработал Karyonix и оригинал выложен тут: reboot.pro/topic/8804-firadisk-latest-00130/

amarao 23 марта 2015 в 16:14

+2

300к IOPS не так уж много. У меня в лабораториях пачка SSD выдаёт больше. Из чего можно сделать вывод, что в сегодняшних реалях tmpfs — не самая быстрая система. Так же как и rbd (ram block disk). Увы. Плюс, на tmpfs нет очереди, так что в некоторых ситуациях некоторые типы нагрузки (с резкими всплесками) будут даже медленее.

Это не ssd такие быстрые, это tmpfs такая медленная.

BupycNet 23 марта 2015 в 16:30

+2

Ну… пачка SSD. Сравнили. Думаю что пачка многоканальной памяти и рейд из опративок вполне могут потягаться в разы.

Причем вы смотрите. у него IOPS на домашней недорогой машине на уровне вашей пачки SSD скорее всего в 10-100 раз дороже суммарно по стоимости его оперативки.

amarao 23 марта 2015 в 16:44

+1

Я не про то, что 'Пачка SSD круто', а про то, что tmpfs медленный. У меня на столе ноутбук трёхлетней давности — он выдаёт 50к IOPS. Рамдиск выдаёт 300к. Не чувствуете дискомфорта?

aokoroko 23 марта 2015 в 17:23

0

Конечно, я согласен, что есть аппаратные решения с бОльшим быстродействием. Например, PCIe SSD и InfiniBand Flash/DRAM, но таки моя статья про недорогую домашнюю систему и чисто программное решение, простое. Да, значение IOPS меня несколько огорчило, ожидалось больше. Однако латентность радует, 0.29 микросекунд.

amarao 23 марта 2015 в 17:47

+1

Кстати, не срастается. Если iodepth=1, то при 1.99 µs (вы не туда смотрите), должно быть 502к IOPS, а не 390к. 1/0.00000199=502512

aokoroko 23 марта 2015 в 18:12

0

В чем же причина? Параметры запуска у меня в командной строке — можете посмотреть. А почему не туда смотрю? В руководствах советуют сравнивать именно clat…

jcmvbkbc 23 марта 2015 в 19:01

0

tmpfs медленный. У меня на столе ноутбук трёхлетней давности — он выдаёт 50к IOPS. Рамдиск выдаёт 300к.

Какой смысл сравнивать файловую систему с блочным устройством?

amarao 23 марта 2015 в 20:57

+1

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

jcmvbkbc 23 марта 2015 в 21:15

0

А, я понял, 300к — с brd, а 50к — с диска, а не с tmpfs. Ok.

ValdikSS 23 марта 2015 в 22:26

+2

tmpfs действительно медленная. По идее, она должна быть быстрее в 3.16+ и еще быстрее в 3.19+. У автора статьи, думаю, в лучшем случае 3.16, но, скорее всего, 3.2 (Debian Stable).

Ну и вообще, мне способ не нравится, честно говоря. Squashfs можно собрать и с lzo, он будет летать и меньше места занимать, да и, к тому же, для squashfs в качестве rootfs уже куча скриптов написано, которые сами вам сделают tmpfs поверх squashfs через тот же overlayfs, который уже есть в ядре. Хочется безопасно эксперементировать с системой? Тогда лучше использовать снапшоты на любой ФС, их поддерживающей, например btrfs. Как эксперимент, конечно, не осуждается, но я не представляю, кому это может пригодится в реальной жизни.

Ну и не стоит забывать об очень, очень противной особенности tmpfs — он не показывается во free. Скажем, у автора 16ГБ оперативки, а tmpfs вдруг разросся до 8ГБ. У автора запущено дофига программ, он хочет запустить еще, везде написано, что оперативки достаточно, а на деле все свопится, или, если свопа нет, не запускается, или oomkiller вообще приходит. Везде написано, что свободно (именно свободно!) 8ГБ оперативки, хотя на самом деле это не так.

aokoroko 24 марта 2015 в 16:24

0

3.16.0-4
Побудило на эксперимент то, что сколько разных LiveCD с squashfs я не перепробовал, скорость запуска приложений не удовлетворила. Она была меньше, чем видно в скринкасте в конце статьи.
А эта особенность tmpfs разве не исправлена?

ValdikSS 24 марта 2015 в 16:53

0

А эта особенность tmpfs разве не исправлена?
Нет, насколько мне известно. Можно только смотреть реальную занятость памяти через /proc/meminfo.

aokoroko 24 марта 2015 в 20:45

0

Как тогда объяснить следующее? Я исполнил вот такой скрипт:

echo 3 > /proc/sys/vm/drop_caches
free
dd if=/dev/zero of=/test bs=1M count=3000
echo 3 > /proc/sys/vm/drop_caches
free

и получил такой результат:

Т. е. я записал на tmpfs файл 3 Гб и free показывает, что свободной памяти стало на 3 Гб меньше, а занятой — больше. Кэши сбрасывал.

ValdikSS 24 марта 2015 в 21:09

0

О, они починили, но у вас все еще нет. Вы должны смотреть не на строку Mem, а на строку -/+ buffers/cache, там у вас значение free не изменилось (почти). А в новом free все выглядит так:

Скрытый текст

valdikss@valaptop ~/witch/it % free -m
total used free shared buff/cache available
Mem: 7871 3195 1302 628 3373 3762
Swap: 0 0 0
valdikss@valaptop ~/witch/it % dd if=/dev/zero of=/tmp/file.a bs=1M count=1500
1500+0 records in
1500+0 records out
1572864000 bytes (1.6 GB) copied, 0.506198 s, 3.1 GB/s
valdikss@valaptop ~/witch/it % free -m
total used free shared buff/cache available
Mem: 7871 3194 145 2127 4532 2264
Swap: 0 0 0
valdikss@valaptop ~/witch/it %

izyk 23 марта 2015 в 17:56

+1

Присоединяйтесь:
en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM
По мне, так самый интересный это: tinycorelinux.net

Мое мнение, во всем этом нет смысла, выигрыш только при запуске, а не удобств полно.
Главный tmpfs — временная Ф.С., ваш КО.
Но для познавательных целей, конечно полезно.

aokoroko 23 марта 2015 в 18:16

0

Кроме запуска, выигрыш в отсутствии амортизации диска, а можно его вообще не иметь. Еще выигрыш в возможности отката всех изменений просто нажатием Reset. Последнее актуально, когда есть мамы-бабушки, ставящие «вход в интернет» и дети.

immaculate 24 марта 2015 в 08:44

0

Бабушки будут ходить в интернет из системы, в которой не предусмотрено обновление хотя бы браузера. Я бы поостерегся.

aokoroko 24 марта 2015 в 17:12

–2

Так sudo apt-get update && sudo apt-get upgrade же при старте ну и потом периодически…

Gorthauer87 23 марта 2015 в 18:14

–1

А через overlayfs такое не сотворить?

SunX 23 марта 2015 в 18:22

0

Это, как я понял, замена UnionFS. Значит оно поможет сохранять изменения в другое место.

jcmvbkbc 23 марта 2015 в 18:23

+1

Что-то я не понял, чем это лучше стандартной initramfs?
Берём нужную нам корневую файловую систему, заворачиваем её в cpio и даём грубу в параметре initrd. Всё.

aokoroko 23 марта 2015 в 18:32

0

Я про это тоже думал, но мне тут не хватает знаний. Нужны ли какие-либо драйверы? Как это сделать в деталях? Буду благодарен, если распишете «для чайника». И чем будет в итоге это? Так и будет initramfs? Как она по производительности в сравнении с tmpfs? Рассчитана ли она на многогигабайтные размеры? Из линуксов «целиком в initrd» я видел только Damn Small Linux с initrd размером 50 Мб.

jcmvbkbc 23 марта 2015 в 18:47

+3

> Нужны ли какие-либо драйверы?
Ничего сверх того, что у вас и так есть.

> Как это сделать в деталях?
встать в корневой каталог корневой ФС, выполнить от рута
find -xdev -print0 | cpio -o --null -H newc | gzip > ...../rootfs.cpio.gz
Больше деталей: www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

> Как она по производительности в сравнении с tmpfs?
По умолчанию она и есть tmpfs.

aokoroko 23 марта 2015 в 18:55

0

Спасибо! Попробую сделать, позже отпишусь.

aokoroko 24 марта 2015 в 20:37

0

Поставил опыт. Увы, вот так просто «в лоб» не работает. Initramfs читается и распаковывается, но затем Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

jcmvbkbc 24 марта 2015 в 22:30

0

Обязательно нужен либо /init в корне, либо параметр ядра rdinit=… Ну и могут быть тонкости, в зависимости от того, как сделан /dev.

robert_ayrapetyan 23 марта 2015 в 21:48

0

Хм, а где тесты fio по записи? Тесты с dd «ни о чем» (http://habrahabr.ru/post/154235/).

По fio — ZFS «из коробки» дает такие цифры на системе 5-летней давности с двумя дешевыми дисками в программном RAID1:

fio -name=iops -rw=randread -bs=4k -size=2G -iodepth=2 -directory=. -ioengine=posixaio
RESULT: read 106045 iops, clat avg: 15.2ms

robert_ayrapetyan 23 марта 2015 в 21:56

0

Диски — не SSD если что…

aokoroko 23 марта 2015 в 22:09

0

Тест fio по рандомной записи делал, а не приложил, потому что он принципиально не отличается. Вот скриншот randwrite: ccosplay.com/fio-randwrite.jpg
Тесты с dd я не соглашусь, что полностью бессмысленны. Задача последовательного чтения или записи большого файла часто встречается. В статьях о некорректности dd указывают на то, что он может не учитывать кэширование, но в данном случае кэширования нет — tmpfs не кэшируется вовсе. Собственно, копирование больших (несколько Гб) файлов в консоли или mc показывает те же результаты, что и dd, и информация о скорости этого копирования не бесполезна.
15.2 — это милли- или микросекунд? ms обычно обозначаются миллисекунды…

robert_ayrapetyan 24 марта 2015 в 00:00

0

15.2 микросекунд (usec), ошибся, пардон…

aokoroko 24 марта 2015 в 01:04

0

Ну вот, а у меня 0.29 usec, что в 50 раз меньше. По идее, это должно влиять на отзывчивость системы в лучшую сторону…

robert_ayrapetyan 24 марта 2015 в 05:37

0

Вообще в случае RAM-хранилищ нужно мерять по lat (у меня он порядка 17 us, у вас — 2 us), т.к. slat кхм… существенно выше clat :) тогда разница получается в 10 раз. Но с точки зрения пользователя с SATA диском (iops ~300 и lat 7000 us) — разница между tmpfs и ZFS несущественна в производительности, зато по набору опций… даже несравнимо.

realscorp 26 марта 2015 в 19:10

0

По-моему, размер файла для теста у вас очень маленький. Эти 2ГБ полностью влазят в ARC и, естественно, отсюда такое большое значение IOPs.

robert_ayrapetyan 27 марта 2015 в 03:21

0

Ну, как бы у автора tmpfs тоже влазит в RAM целиком. Я лишь хотел показать, что с достаточно большим объемом RAM и дешевыми HDD, ZFS является вполне себе достойной альетративой SSD и tmpfs.

valplo 23 марта 2015 в 22:08

0

Еще бы execute-in-place приделать — и будет совсем хорошо.

Pilat 23 марта 2015 в 23:16

0

По-оему, обычного SSD вполне достаточно для обеспечения практически необходимого быстродействия.
Ну какая разница сколько грузится linux, если на нормальных серверах время старта самого сервера до операционной системы изменяется в минутах. А на ноутбуках, где с диском как раз беда, оперативной памяти много не бывает.

За статью всё равно спасибо — вдруг пригодится.

aokoroko 23 марта 2015 в 23:28

0

Так не сколько грузится сам linux (раз в день и реже можно и подождать немного), а сколько грузится каждое приложение, работает оно с накопителем или с ОЗУ, с какой латентностью и т. д. Вот никто особо не воздал должное тому, что латентность памяти на несколько порядков меньше латентности любого SSD (микросекунды против миллисекунд)…
А почему на ноутбуках не бывает много оперативной памяти? Чаще всего есть два слота, можно поставить 2x8 Гб, я сам ставил…

Pilat 24 марта 2015 в 00:40

0

Так дорого получается ноут апгрейтить. Два слота на моделях выше среднего уровня. И ставить имеет смысл на ноут с хорошим процессором. В результате получается золотой ноутбук, который всё равно работает плохо по сравнению с десктопом.

А приложения грузятся всё равно достаточно быстро и с SSD. Тот же FireFox — несколько секунд, опять же не каждую минуту его грузят.

aokoroko 24 марта 2015 в 01:00

0

Выходит несколько дорого, но что делать? Ноутбук используется как раз там, куда десктоп не возьмешь — в командировке, например, или вот в прошлом году пришлось мне лечь в больницу на месяц, а на работе было нежелательно делать паузу. Работа связана с экспертной оценкой большого числа веб-страниц, надо, чтобы браузер летал, чтобы ожидание открытия вкладок, подгрузки контента было минимальным, потому что секунды превратятся в итоге в часы. Пришлось утворить рам-загрузку на ноутбуке. Только в прошлом году я еще не знал, как это сделать в Linux, сделал для Windows — на десктопе-то давно уже так работало. Да нет, куча ноутбуков 16" за $350 была с двумя слотами под память, двуядерный Pentium 2.2 ГГц, помнится.

НЛО прилетело и опубликовало эту надпись здесь

Meklon 24 марта 2015 в 09:29

0

/tmp и так в tmpfs, судя по дефолтном fstab. Kubuntu 14.04.

НЛО прилетело и опубликовало эту надпись здесь

nikitasius 24 марта 2015 в 00:14

+1

А какая у вас память используется?
Я прогнал у себя на рабочем сервере (там тоже tmpfs создан для некоторыз проектов):

Скрытый текст

aokoroko 24 марта 2015 в 00:40

+1

DDR3 Kingston 1333 МГц 2x8 Гб (CPU Sandy Bridge i5 2310 2.9 ГГц), одним словом, домашняя машинка. Надо полагагать, на сервере с высокочастотной / многоканальной памятью будет гораздо больше IOPS, что у вас и видим.

lubezniy 24 марта 2015 в 00:15

+1

На практике можно tmpfs применять и не столь радикально для увеличения нагрузочной способности, если ресурсы ограничены. Довелось как-то сооружать Web-сервер, с которого через канал 100 МБит/с иногда весьма активно скачиваются файлы объёмом примерно от 30 до 150 МБайт. В машинке, отведённой под этот сервер, был только один отсек для жёсткого диска (да и то 2,5 дюйма), и были сомнения насчёт работы сервера под нагрузкой, но зато можно было поставить довольно много ОЗУ, и появился резон читать файлы под скачивание не с диска, а из памяти. Накатил на этот диск Linux, в качестве Web-сервера поставил nginx, а Web-каталог ему сделал в tmpfs. При загрузке ОС скрипт автозапуска до старта nginx готовит файловую систему, в ней делает Web-каталог и копирует туда с жёсткого диска файлы под скачивание. Другой скрипт, запускаемый по cron, периодически сверяет содержимое эталонного каталога на жёстком диске с каталогом в tmpfs и обновляет файлы в Web-каталоге при обновлении таковых в эталоне. В итоге цели поднятия этого сервера были достигнуты; машинка держит нагрузку с приличным запасом; думаю, при необходимости можно будет скорость канала ещё в несколько раз увеличить.

pansa 24 марта 2015 в 02:04

0

Господа, простите, ночь, может я туплю… А что если так:
— берем любой линкус
— выдаляем tmpfs раздел на нужное количество гигов
— ставим виртуальную машину с любой желаемой ОС
— размещаем файлы виртуалки на tmpfs
— запускаем, работаем, обновляем ОС, ставим программки
— выключаем
— синкаем файлы с tmpfs на любой персистентный носитель
— profit?

Ну да, будет просадочка на виртуализацию, но на современном железе она минимальна. Зато плюсы какие. Не? Попробуйте кто-нибудь? :)

aokoroko 24 марта 2015 в 02:23

0

Ну в принципе хорошая мысль. Только я опасаюсь, что на домашнем железе не хватит оперативной памяти, если в виртуальную машину ставить Windows x64. Зело она велика по объему, особенно при обновлении много Гб требуется. А если на нее еще MS Office поставить, то тем более.

zenden2k 24 марта 2015 в 02:37

+1

А ГИМП даже на рамдиске грузится дольше всех…

aokoroko 24 марта 2015 в 03:30

0

Да, он такой. Написан он так. Что поделать.

nitro80 27 марта 2015 в 04:28

0

НЕ использовать ГИМП?

aokoroko 27 марта 2015 в 07:24

0

А использовать что?

nitro80 27 марта 2015 в 11:53

0

Krita хвалят

TrueBers 24 марта 2015 в 08:39

0

Anything sync daemon же!

Ti_Fix 24 марта 2015 в 09:24

0

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

Если не сложно, опишите более подробно — как это у Вас реализовано.

aokoroko 24 марта 2015 в 13:31

0

Выше дали ссылку geektimes.ru/post/185172/
Оказывается, уже написали до меня. Но там большая статья, у меня несколько проще, хотя основа та же — grub4dos и firadisk.

Livid 24 марта 2015 в 15:16

+1

Во-первых, статья решительно ни о чем. Человек открыл для себя tmpfs. Поздравляю, он существует уже лет 27 вообще и около 14 лет в линуксе.
Во-вторых, для Вашего сценария достаточно весь образ системы засунуть в initramfs: начиная с ядер 2.6, если в ядре есть tmpfs, то rootfs — это tmpfs (если не указано иное в параметрах ядра) — см. www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt Ради чего делать вторую tmpfs поверх — непонятно.

aokoroko 24 марта 2015 в 16:27

–1

Я обещаю поставить опыт с initramfs. Если всё так, то это здорово упрощает дело и статья действительно становится праздной. Но все же у меня есть сомнения, что все пройдет гладко. И нужна ли правка fstab в этом случае?

aokoroko 24 марта 2015 в 20:37

–1

Поставил опыт. Увы, вот так просто «в лоб» не работает. Initramfs читается и распаковывается, но затем Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Видимо, нужны некторые ключевые детали, о которых вы не упомянули…

Livid 24 марта 2015 в 23:45

+1

По ссылке же все написано… ядро ищет init в корне initramfs, а у Вас он в /sbin/init. Сделайте симлинк или передайте ядру параметр rdinit=/sbin/init. Не забудьте убрать / из fstab, а то у Вас все посыплется на попытке fsck.

ValdikSS 24 марта 2015 в 17:02

0

В systemd прилетел коммит, который позволяет делать точно то же, что описывает автор, стандартными средствами.
www.phoronix.com/scan.php?page=news_item&px=Systemd-Stateless-Root

aokoroko 24 марта 2015 в 17:23

0

Я вижу только fstab генератор для root on tmpfs, а остальное как? Всё в initramfs.cpio.gz?

ValdikSS 24 марта 2015 в 17:25

0

Да.

aokoroko 24 марта 2015 в 20:41

0

Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Пробовал и со своим fstab, и с пустым — то же самое. Ядро пытается монтировать root fs на блочное устройство???

Cheater 27 марта 2015 в 15:37

0

ИМХО это переводится как «Невозможно монтировать rootfs, расположенную на блочном устройстве».

Сообщение, как правило, означает, что указанного блочного устройства просто-напросто нет. У меня такое наблюдалось, когда ОС находилась на usb флешке, а usb драйвера в initrd включены не были. В вашем случае не знаю в чём дело. Предположу, что в скрипте init пропущен этап заполнения /dev. Измените скрипт init, вставив вызов "/bin/bash -i" перед попыткой скрипта что-то смонтировать. Потом как попадаете в этот bash при старте, уже в интерактивном режиме пытайтесь что-то смонтировать, выяснить что не так с системой, и т.д.

immaculate 24 марта 2015 в 17:28

+1

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

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

роутеры

платежные терминалы

способы этого достичь

монтировать надежную fs в read-only

squashfs

tmpfs

другое

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

Мне непонятно, чего хотел добиться автор, и почему его решение хорошее. Запускать LibreOffice за 0.5 c вместо 1 с? Так никто обычно не запускает тяжелые программы, чтобы сразу из них выйти. Ну и полноте жаловаться, на SSD все и так запускается достаточно быстро.

aokoroko 24 марта 2015 в 18:01

0

После запуска программы разве она больше не производит дисковых операций? Еще как производит. SSD и кэширование придумали именно для этого. Однако можно и быстрее, что я и продемонстрировал. Я реально в такой системе работаю (как в Linux, так и в Windows), и ни за какие коврижки не соглашусь обратно на HDD и даже на SSD. Потому что медленно. Ну и на одной из работ критично, смогу я открыть и исследовать, например, 1000 веб-страниц за 8 часов или же за 5 часов, потому что это нужно делать ежедневно, и когда узкое место — моя собственная производительность, то это одно, а когда подтормаживает машина, то это очень печалит и вынимает з/п из кошелька и уменьшает время на отдых.

immaculate 25 марта 2015 в 06:04

0

Я не знаю точно, как устроен firefox, но не уверен, что файловая система на tmpfs ускоряет открывание 1000 вкладок. Первый запуск, возможно. Но открытые страницы firefox хранит не на диске, а в памяти, которую вы у него забрали. В любом случае, возможно, достаточно было бы перенсти профиль firefox на tmpfs.

Cheater 25 марта 2015 в 01:58

+3

У вас личная неприязнь к автору? Это уже второй коммент с общей мыслью «не знаю зачем эта ваша initrd-only ОС, у кого-то избыток свободного времени, у меня на SSD всё работает с той же скоростью.» Высокомерие — плохая черта. Статья нужна потому, что она демонстрирует, что можно поместить ОС за пару простых действий целиком в память. Это как минимум стимулирует тех читателей, кто раньше не знал / не задумывался о такой возможности, глубже познакомиться с устройством init в дебиане, с initramfs/unionfs, задуматься о плюсах переноса какого-нибудь содержимого с харда на виртуальный диск. Люди разные, машины и задачи у них разные, у кого-то SSD, у кого-то HDD, у кого-то бездисковый тонкий клиент. В комментах выше пару кейсов привели, когда initrd нужен.

immaculate 25 марта 2015 в 05:55

+1

Это не высокомерие. Удивлен, что столько внимание привлекла статья, которая не рассматривает ни альтернативные решения, нет никаких сравнений производительности (я вот не уверен, что производительность в целом выше, так как производительность — это не только скорость запуска firefox), надежности, совершенно не продуманы вопросы обновления.

Автор описал только два преимущества:
— быстро запускаются приложения (что, в общем, не так уж важно при реальной работе)
— можно выключать/перезагружать компьютер в любой момент (что, в общем, тоже не особо необходимо в обычной работе, так как ничто не мешает выполнять полноценный shutdown)

aokoroko 25 марта 2015 в 15:43

0

Прошу прощения, но это применительно к подобной стстеме для Windows они не продуманы, а эта статья о Linux. apt-get update && apt-get upgrade после старта ведь решает вопрос обновления, разве нет?

TrueBers 25 марта 2015 в 09:25

0

Поддержу комментатора immaculate.

Как-то пару лет назад, когда приобрёл 16 гигов оперативки, так же стало интересно, как это можно систему запихнуть в оперативку и ВСЁ БУДЕТ ЛЕТАТЬ!!!!1

Долго ковырялся, копал, перепробовал кучу вариантов. Поработал в таком режиме пару недель, вся эта канитель взбесила — купил SSD. Поставил, оттюнил, разницы с рам-диском на глаз не заметил. Зато, ПОСТАВИЛ — РАБОТАЕТ.

Потом стал замечать, что занято примерно 8 гигов максимум, остальное забито кешем. Выделил 4 гига под рам-диск для временных нужд: что-то скомпилить по-быстрому, какой-нить здоровый файл обработать. Всё, больше не нужно ни для чего.

Это я про винду.
В линуксе же есть, например, anything-sync-daemon, который любую папку пихает в рам и как положено там всё rsync'ает. Не нужно изобретать велосипеды, всё до нас уже изобрели. Это всё интересно исключительно для собственного развития: понять как оно там работает, поковырять, разобраться, допереть, что уже давно кем-то реализовано лучше, и воспользоваться готовым решением.

aokoroko 25 марта 2015 в 15:39

0

Теперь представим ситуацию: у вас над ухом стоит начальник, который с делегацией, и вам нужно очень быстро показать ему что-то. Вы запускаете это что-то и… именно в этот момент в кэше этого нет, в рам были отправлены другие папки, произошло еще что-то, и т. д. и т. п. Начальник ждет ровно 3 секунды и идет дальше с делегацией, вы не получили ничего. Я утрирую, но общий смысл в том, что если в системе есть медленные устройства, то это обязательно так или иначе будет сказываться. Я бы хотел, чтобы об этом вообще думали, искали новые решения, а не довольствовались тем, что уже изобретено. Да, данный способ имеет недостатки. Придумайте лучший, еще более быстрый, без недостатков, может быть, вообще аппаратный, чтобы при помощи паяльника каждый мог сделать у себя дома.

TrueBers 25 марта 2015 в 22:31

0

В большинстве систем даже с SSD самым медленным устройством оказывается процессор, т. к. ввод-вывод начинает упираться именно в него, в постоянную смену контекста потоков, промахи кеша, миллионы неоптимальных сисколов без scatter-gather и т. д. Все эти тесты слишком синтетичны и не отражают реалий современного быдлокодерства. Тот же Экслипс хоть на марсоходе запускай, меньше, чем за 4-5 секунд он не стартует без тонкой настройки.

А мне то зачем придумывать? Меня вполне устраивает мой ссдшник с его производительностью и демоном синхронизации с рам-диском.

Я абсолютно не против поиска подобных костылей, сам раньше позволял себе копаться в чём-то, досконально разбираться, а сейчас пришло понимание, что лучше потратить в 10 раз меньше времени, воспользоваться готовым решением, и потерять максимум 20% производительности.

aokoroko 25 марта 2015 в 23:16

0

Как человек, в 2015 году пишущий оконные приложения для Win 8.1 x86 на ассемблере, вполне соглашусь с первым абзацем.

immaculate 26 марта 2015 в 08:02

0

О! С этого и надо было начинать статью. Я бы не стал тратить время на комментирование. :)

aokoroko 26 марта 2015 в 16:44

–2

А узнав, что Алан Тьюринг был геем, вы бы стали читать его труды по логике? Вы считаете, что его ориентация ухудшила качество его работ? А шизофрения Джона Нэша — ухудшила качество его математических работ? Или, может быть, язык ассемблера — это что-то, что хуже педерастии и шизофрении?

immaculate 26 марта 2015 в 17:52

+3

Вы очень лично все восприняли, мне жаль. А я не осуждаю, но и не одобряю. Я просто оптимизирую жизнь, программы, системы по другому принципу. С моей точки зрения, считать такты на ассемблере бессмысленно, потому что пока я буду их считать, поезд уже уйдет, и программа будет не нужна ни мне, ни кому-либо другому. Ложка дорога к обеду.

Тратить жизненное время на перемещение всего в tmpfs для меня из той же оперы. Я может быть получу ускорение, если повторю ваш опыт, даже предусмотрю обновления и какую-то персистентность программ и данных. Но мне это не нужно, так как без бенчмарков мне кажется, что исчезнувшая память отъест, например, кэш у postgresql и других программ, и на самом деле моя работа станет медленнее и неудобнее… И все это решение какое-то неизящное, непродуманное, непроверенное.

Как у мотоцикла люди отпиливают глушитель, потому что громко (в междурядье замечают), круто, пару лошадиных сил прибавляет. А потом у них поршни прогорают на самом деле.

В общем, нет у меня ни высокомерия, ни осуждения. Какая-то эмоция впрочем есть, потому что все же в нескольких комментариях отметился.

aokoroko 26 марта 2015 в 18:16

–1

Вы осуждаете, и не просто, а именно «не читал, но осуждаю» (с), потому что не изучаете и не тестируете, а «без бенчмарков мне кажется». И здесь не пара лошадиных сил, а по ряду параметров разница на порядок с SSD и на несколько порядков с HDD.
Написание программ на ассемблере не занимает больше времени, чем на любом другом языке, и не является более сложным и трудоемким, чем на любом другом языке.

hopungo 9 апреля 2015 в 06:24

–1

Таки Алан Тьюринг был педофилом, разве нет?

SunX 9 апреля 2015 в 13:37

+1

Таки нет, лечили его именно от гомосексуализма. Про педофилию никогда не слышал.

poxvuibr 10 апреля 2015 в 13:00

0

Ну если бы Алан Тьюринг высказал своё мнение о том, что мужчины во всех отношениях красивее и привлекательнее женщин, я бы не стал прислушиваться к его мнению.

hopungo 9 апреля 2015 в 06:23

0

Мне непонятно, чего хотел добиться автор, и почему его решение хорошее. Запускать LibreOffice за 0.5 c вместо 1 с? Так никто обычно не запускает тяжелые программы, чтобы сразу из них выйти. Ну и полноте жаловаться, на SSD все и так запускается достаточно быстро.

Рискну предположить, что в большинстве случаев тяжёлые программы висят постоянно в памяти именно из-за того, что они тяжёлые, и операция запуска отнимает слишком много времени.

Имхо, для полноценного решения надо полностью менять концепцию «быстрая память/медленная память» и разрабатывать какую-нибудь TurboRamOS.

Venom13 24 марта 2015 в 17:58

0

Эффектно…
Но лично для меня, без авто обновления архива, не применимо.

P.S. А в гибернацию такая система ляжет? ;)

aokoroko 24 марта 2015 в 18:03

0

Гибернацию не проверял, так как все системники работают 24/7. Скорее всего, да, при наличии достаточно RAM.

SunX 24 марта 2015 в 18:49

+1

RAM — это Suspend, а гибернация на диск делается. Впрочем не вижу никакой причины не работать гибернации, только своп для этого нужен большой.

Ezhyg 24 марта 2015 в 21:05

0

STR — Suspend to RAM, STD — Suspend to Disk или они нынче больше не работают?

SunX 25 марта 2015 в 14:32

+1

Не совсем понял, о чем Вы. Я же о том, что Гибернацией (как правило) называют Suspend to Disk. Т.е. сбрасывание всей памяти на диск (в Линуксе это, как правило своп) и отключение питания процессора и памяти.
А Suspend to RAM часто (так скажем раньше) просто называют Suspend, т.е просто приостановка всех приложений и перевод процессора в спящий режим.
Если я ничего не напутал, то исходя из этого большое количество RAM совершенно не нужно для гибернации, а даже наоборот — несколько вредно.

Ezhyg 25 марта 2015 в 14:41

0

Я только процитировал термины энергосберегающих режимов, что они оба Suspend :).

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

Что обсуждают

Сейчас

Вчера

Неделя

Android Q поможет жестко «привязать» мобильный телефон к оператору связи
4,9k 14

Как экономить свое и чужое время на собеседованиях, или немножко о заблуждениях HR
28,5k 428

Японский ядерный могильник в Приморье или место утилизации АПЛ Тихоокеанского флота
2,2k 6

Роскомнадзор возобновил попытки блокировать Telegram
47,7k 170

Большая часть текстов в интернете написана безумцами
3,3k 10

Ослабляем гайки в правилах Хабра
29,3k 598

Не покупайте смартфоны 5G – хотя бы в ближайшее время
37,2k 199

Возобновляемая энергетика: слова и их значение
8,1k 125

Хрупкий кабель дисплея MacBook Pro: очередная ловушка, в которую загнали себя инженеры Apple
25,4k 111

Эволюция развития автомобильных двигателей с начала 90-х годов
6,1k 59

Ослабляем гайки в правилах Хабра
29,3k 598

Получить работу в Германии станет проще
46,1k 348

Как научить людей использовать Git
49,6k 300

Один гигантский шаг для машины, играющей в шахматы
36,4k 253

Есть мнение: IPv6 провалился — кто и почему так считает
41,7k 235

Самое читаемое

Сутки

Неделя

Месяц

Роскомнадзор возобновил попытки блокировать Telegram
+70 47,7k 33 170

Не покупайте смартфоны 5G – хотя бы в ближайшее время
+56 37,2k 67 199

Ослабляем гайки в правилах Хабра
+266 29,3k 59 598

Зрители не могут отличить нативную картинку 4K от интерполяции
+34 29,7k 31 130

Как научить людей использовать Git
+53 49,6k 634 300

1 февраля 2019 года ваш сайт может перестать работать
+80 110k 145 149

Крупнейший дамп в истории: 2,7 млрд аккаунтов, из них 773 млн уникальных
+80 99,3k 225 139

Юбилейный Android 10 (Q). Что известно уже сейчас?
+52 49,8k 31 102

Как научить людей использовать Git
+53 49,6k 634 300

Новый способ угона аккаунтов «оптом» через получение доступа к сервисам оператора сотовой связи
+66 47,2k 64 86

Одноразовые зарядные устройства. За что нам это?
+322 125k 157 375

1 февраля 2019 года ваш сайт может перестать работать
+80 110k 145 149

Почему меня нервируют отказы современных SSD
+34 102k 60 289

Свершилось! Космический корабль NASA New Horizons вышел на связь с расстояния в 4 миллиарда миль
+58 101k 37 144

Крупнейший дамп в истории: 2,7 млрд аккаунтов, из них 773 млн уникальных
+80 99,3k 225 139

Хабр рекомендует
Разместить

Тест: чем занять себя в аэропорту в ожидании рейса

Проверяем тестом знание современных цифровых сервисов

Аккаунт

Войти

Регистрация

Разделы

Публикации

Хабы

Компании

Пользователи

Песочница

Информация

Правила

Помощь

Документация

Соглашение

Конфиденциальность

Услуги

Реклама

Тарифы

Контент

Семинары

Приложения

© 2006 – 2019 «TM»

Настройка языка

О сайте

Служба поддержки

Мобильная версия

Настройка языка

Интерфейс

Русский

English

Язык публикаций

Русский

English

Сохранить настройки