Пользователь
0,0
рейтинг
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):

randread 4K fio

В работе


Вывод команды 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:

Артур Фирюлин @aokoroko
карма
19,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +3
    habrahabr.ru/post/164147/
    вы можете возразить, что появятся оверхед от squashfs, но по факту это не заметно.
    • +4
      … потому, что оверхед от squashfs обычно пересиливается ускорением за счёт уменьшения объёма пересылаемых данных
  • +2
    Как вы решаете проблему, если нужно что-то доустановить или изменить конфигурацию?
    Каждый раз целиком пересоздаете ram.tar.gz?

    Я давно хотел сделать что-то подобное для Windows и SSD, чтобы система свои постоянные обращения к диску делала в рамдрайв, и только пару раз в день скидывала изменения на SSD. И быстро и срок службы продлевается. Но эту задачу решить не удалось. Инструменты типа рамдрайв скидывают только полный дамп на диск…
    • +1
      Я тут так подумал, что можно попробовать таки хранить в полноценном разделе всё, из него всё и копировать в tmpfs, и заскриптить при помощи inotify сбрасывание обратно, но там достаточно много скорее всего особенностей.
    • 0
      У меня, кроме производительности, была еще цель создать неубиваемую систему, поэтому изменение архива никак не автоматизировано, оно делается редко, вручную, сразу после перезагрузки, вносятся необходимые изменения и делается новый архив. Такие предосторожности, чтобы не доустановить что-нибудь плохое. Но это если накопилось много претензий и хочется переделать. А так вообще в дебиане очень просто что-то доустановить из репозитория. Можно неделю, месяц работать не перезагружая систему, делать с ней все, что заблагорассудится, ставить софт и т. д. Единственно, конечно, объем установленной RAM ограничивает.
      • +2
        В puppyrus была подобная система. Там есть основной образ системы + squashfs архив с изменениями. Причем насколько я помню, там можно настроить так, чтобы все файлы загрузились в оперативку и чтение было с нее, а например через какие то периоды времени в фоне данные синхронизировались с squashfs. Или при выключении можно сохранить не помню.

        И там гибкость была в том, что можно было создать несколько squashfs архивов с различными конфигурациями, и грузить их если что либо необходимо. Можно было на 2х гигах оперативы загружать к примеру либо образ для работы с графикой, а потом быстро переключаться на образ для игр, или например образ для разработки с различными IDE.
        • 0
          Угу, я слежу за puppyrus, он развивается, вот свежий, построенный на Арче: PuppyRus-A
      • 0
        А обновления как? Каждый раз при загрузке системы?
        • 0
          Увы, да. С быстрым каналом в Интернет большой проблемы в этом нет. Если же машина будет использоваться без сети (как домашний кинотеатр или печатная машинка), то и обновления особо не нужны…
    • +1
      У меня три года рабочие станции жили на EWF — как раз то что вам нужно: habrahabr.ru/company/pt/blog/155135/
      • 0
        Что-то очень похожее на LVM
        • +1
          Там ФС живёт на диске, изменения кэшируются в оперативке и при перезагрузке херятся. Если нужно внести изменения в ФС, просто пинаешь специальный батник и тогда при перезагрузке или выключении машины кэш сбрасывается на диск. Очень помогало от криворуких пользователей и вирусняков. Все проблемы решались перезагрузкой. Одно неудобство было только при установке тяжёлого софта. Например на машине с 512Гб оперативки не получалось вкатать OpenOffice т.к. он при установке записывал на диск больше данных, чем умещалось в оперативке. Самым активным юзерам делали апгрейды до 1-2Гб, но 70% народу сидело на 512Мб вполне комфортно.
  • +6
    Очень круто. Как раз памяти много. Вы можете пояснить как данные сохраняются? например, я обновил софт или новый поставил. Я упустил этот момент. Плюс home раздел на ssd и в tmpfs не заливается, наскрлько я понимаю.
    • +13
      Да никак не делается. Автор сначала обругал squashfs (он якобы медленный — но скромно умолчав о том, сколько занимает зачитывание и распаковка всего тарболла разом с носителя в tmpfs), потом второй раз обругал squashfs (якобы там сложная многослойная система монтирования) — но в предложенном варианте все эти «проблемы» с persistency просто игнорируются — всё живет до тех пор, пока есть питание и жива система.
      • +1
        Да, согласен, у меня нет никакого persistency, зато можно безопасно экспериментировать, не боясь убить систему. Это, можно так сказать, не баг, а фича, что после перезагрузки происходит фактически откат ОС на эталонный образ — так было задумано ради безопасности.
        Тарболл у меня вышел около 600 Мб, зачитывание и распаковка его происходит быстро. Да и не очень это критично делать раз в день…
        • +2
          Не монтировать по умолчанию файловые системы с постоянного носителя (а он у вас по любому же есть — вы же не из сети тарболл берете) — это гигантский прорыв в области безопасности, да…
          • +3
            Да ещё и после перезагрузки автор получает систему без обновлений безопасности.
            • 0
              А вот это спасибо, что заметили. Применительно к Debian, видимо, стоит сразу после перезарузки исполнять apt-get upgrade?
              • 0
                apt-get update перед этим не забудьте.
                • +1
                  Да-да, конечно, спасибо, я забыл упомянуть, это необходимо.
              • 0
                Ядро обновить так просто не получится.
                • 0
                  Уже много лет получается.
                  • +1
                    Возможно я делаю что-то не так, но у меня после apt-get upgrade нужно перезагрузиться, чтобы запустить новое ядро.

                    Да, я слышал про kexec, но мы тут обсуждаем apt-get upgrade.
          • 0
            Но ведь произвести несанкционированные изменения файлов внутри архива на рид-онли носителе практически невозможно, в отличие от файловой системы на обычном носителе. В течение некоторого времени после загрузки мы можем быть уверены в «чистоте» системы. Я ошибаюсь?
            • +3
              Мне очень нравятся «практически невозможно» и «в течение некоторого времени мы может быть уверены» :) Это как «немножко беременна».

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

              «Некоторое время», при условии наличия в сети активного атакующего со свежим remote root exploit'ом, будет стремиться к нулю. За примерами даже далеко ходить не надо — DHCP-сервер злоумышленника с ответами специального вида + Shellshock + достаточно старый dhclient / dhcpcd = исполнение произвольного кода из под root еще на этапе загрузки системы и получения IP-адреса.
              • 0
                Упомянутый тарболл хранится также на CD-R и на флешках, контроллер которых перепрограммирован и представляется CD диском, то есть аппаратно read-only. Если на read-write носителях он будет перепакован, то я это замечу по изменению его контрольных сумм?
                • 0
                  Если у вас есть внешняя сущность, с которой сравнивать (контрольные ли суммы или сами файлы) и сам процесс сравнения — то, разумеется, заметите. Если это не внешняя сущность, то никто не мешает malware модифицировать процесс сравнения так, чтобы он показывал, что все хорошо, когда на деле руткит будет внедрен.

                  Впрочем, все это уже относится к области работы IDSов и антивирусов — там уже до нас с вами накоплены многие годы опыта и придумана масса вещей. И в этом месте «обычный компьютер + IDS или антивирус» как бы не будет толком ничем отличаться от «компьютер с tmpfs root + IDS или антивирус».
    • –3
      Когда я ставил Debian с нуля, поставил ВСЁ в один раздел. Т. е. /home тоже архивируется в образ для рам-загрузки.
      Обновления да, не сохраняются. Данные, с которыми работаю, сохраняю на те носители, что есть — флешки, облака, HDD есть в компе не один…
  • +3
    Кстати, заодно хочу спросить — никто не знает как более агрессивно усилить кэширование? Память простаивает) стоит preload.
    • +9
      Я думаю, что все кэшируется и так максимально оптимально. Такие «вопросы» и «руководства» появляются, когда у человека мало реальных задач и много свободного времени.

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

      На горождении костылей с tmpfs/squashfs я бы потерял в разы больше времени, а так же наверняка потерял бы не раз несохраненную работу, что еще хуже.
    • 0
      А у вас своп-файл включен? Попробуйте отключить — нагрузка на память возрастет, снизятся затраты времени на своп. Когда на компьютере было достаточно памяти (с WinXP), я именно так и работал. Значительно повышается производительность.
    • +2
      Что такое «усилить кэширование»? Где? В linux практически любое обращение к диску прозрачно кэшируется VFS'ом, выделяя под это дело всю свободную в данный момент память. Упрощенно. Так что в линуксе память не простаивает, не думайте, что вы один об этом подумали =)
    • 0
      А swap выключен?
      • 0
        Включён. Его вроде некошерно отрубать совсем. Только не раздел, а файл, который растёт динамически.
        • 0
          Тогда, если хочется кошерно vm.swappines на ноль ставить.
          P.S. без свапа уже лет 5, единственная проблема — некошерно.
          • 0
            Хм. Попробую)
    • 0
      /etc/sysctl.conf
  • –11
    СЦ) опиши как NTFS сделать в RAMDisk подробнее (то, что в первом абзаце)!!!)))
  • +2
    Расскажите, как вы втиснули Windows в 16 ГБ.
    Или у вас там XP?
    • +1
      Да, сколько у Автора было оперативки?
      • 0
        Вопрос хороший. Сейчас у меня: C:\Windows\ 32GB; C:\ProgramData\ 23GB; C:\Program Files\ 12GB; C:\Program Files (x86)\ 19GB. итого 87 GB.
        • +2
          Сразу после установки Win 8.1 x86 на диске C: было занято 2.7 Гб, после установки нужного мне софта стало занято 4 Гб. Дело в том, что использовался подготовленный дистрибутив. Нет, не скачанный где-то в сети, а сделанный самостоятельно из оригинала Microsoft без использования каких-либо программ «для урезания» (которых сейчас развелось много), а только с помощью dism и regedit.
          Вот я не знаю, подскажите, не будет ли против правил написать об этом статью на Хабр? Вроде бы Microsoft не разрешает производить подобные манипуляции со своими дистрибутивами?
          • +2
            Политику MS не подскажу. Но конфигурация ОС вполне в духе Хабра. Однако, дюже любопытно, куда предусмотреть обновления (и резерв на откат), которые растут из недели в неделю. Не уж то целевая конфигурация «для школьного кабинета информатики; моей бабушке» высвобождает такие резервы по оптимизации размеров?
            • +1
              В отличие от Linux, обновления Windows обычно требуют перезагрузки, так что Windows на рам-диске не обновить никак. Чтобы обновить, понадобится ее грузить обычным способом. Но есть удобная технология от M$ — VHD диск. Его можно грузить обычным способом для настройки, обновления и т. д. и в RAM для быстрой работы.
              • 0
                Есть очень удобная технология у linux — squashfs. Вы можете вместо tar.gz архива писать в архив squashfs. Если вам нужно обновить конфигурацию, вы можете загрузиться с примонтированным файлом squashfs и работать с ним. А потом можно загрузиться выгрузив его весь в RAM.
                • 0
                  А можно squashfs примонтировать на запись?
                  • 0
                    Нет, нельзя придется как и в случае tar распаковать, поменять, запаковать. ну или изменения положить в отдельный squashfs файл
          • +1
            Если не решитесь на статью — то накидайте ходя бы примерное направление куда гуглить, что починать.
        • 0
          Строго говоря Program Files — не совсем операционка. У меня стоит семерка установленная еще в 2009. Изначально занимала около 15Гб, а сейчас раздулась до примерно 25 (в основном за счет winsxs, у которго как-то туго с чисткой хлама)
          • +2
            8 октября 2013 года вышло рекомендуемое обновление KB2852386 для Windows 7 SP1 support.microsoft.com/kb/2852386. Оно добавляет функцию очистки WinSxS в утилиту «Очистка диска»
            image
            Работает не так хорошо, как в восьмерке, но работает.
    • +2
      У меня там Windows 8.1 и сейчас я пишу этот коммент в ней.
      Вот как выглядит диск C:, который расположен в RAM:
      image
  • 0
    Тоже экспериментировал с системой в памяти — создавал виртуалку, жесткий диск которой полностью был в памяти — потрясно быстро работает… но столкнулся с проблемой сохранения изменений после обновления например — каждый раз экспортировать напрягало…
    Кроме того — не совсем согласен с неубиваемостью — если выключат электричество или система наглухо зависнет — все изменения пропадут же?
    • +1
      Под неубиваемостью скорее всего имелась в виду возможность любую поломку вылечить ресетом. По поводу пропадания изменений: я бы не сказал, что прямо все изменения исчезают. Они пропадают ровно по тому же принципу, как и в обычной системе на hdd: то, что было в памяти — пропадёт, то, что было на hdd/nfs/samba/… — не пропадёт. Т.е. никто не мешает, например, загрузить ОС в память, как делает автор, затем примонтировать HDD или NFS шару и редактировать данные там.
    • 0
      Вы правы, если пропадет питание (UPS поможет) или зависнет наглухо (тут уже да, не поможет ничего), то пропадут изменения ОС. Но это, мне кажется, не очень страшно. Под неубиваемостью я имел в виду свойство неизменности тарболла. Если система наглухо зависнет, я нажму Reset на системнике и через минуту уже буду в неизмененной системе.
      • –2
        Мне кажется, если система наглухо виснет, надо решать проблему в железе или софте, который вызвал это зависание, а не городить черти-что на RAMDISK.

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

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

        Когда решаешь настоящие задачи, как правило, открываешь одно-два приложения, и работаешь в них. Поэтому мне вообще непонятна цель подобных извращений — не могу придумать workflow, в котором надо непрерывно открывать и закрывать тяжелые приложения.
        • 0
          По вопросу «нагухо виснет» вы отвечайте, пожалуйста, не мне, а timerbulatov. У меня такой проблемы нет и статья не о решении проблем зависания. Также она не о RAMDISK, который есть блочное устройство. Ну и закрывать приложения не обязательно. На «черти» и «извращения» ответил в другом месте.
        • 0
          Скорость записи на SSD все же гораздо ниже, чем скорость записи на диск.
          Я наглядно вижу, что firefox на Ramdisk живет быстрее чем на SSD. Вдобавок это как раз то, что чаще всего пишет ненужные (временные файлы) на диск. А к чувству «SSD не жалко» я только начал привыкать.

          Даже начинаю думать, что надо покупать два SSD — большой для системы, и маленький но быстрый для всяких временных папок, кешей, свопа, на котором не будет лежать критической инфы вообще, и его уже менять по мере проблем.
          • 0
            У меня, например, Firefox начинает ощутимо тормозить, когда остается мало памяти (другой процесс много съел, например). Если я его скопирую в RAM-диск, то этой памяти станет еще меньше…
            • 0
              А я достаточно часто открываю и закрываю Firefox. Выделить 300 мегабайт для рамдиска с firefox и far мне не кажется слишком напряжных в системах с 4гб и выше.
    • +2
      На счет изменений можно посмотреть в сторону UnionFS и ее аналогов (вроде в Linux в последнее время это все встроено в mount и ядро) т.е. вы как-то раз делаете снэпшот файловой системы в удобном для Вас виде (squashfs, tar.gz, etc..) монтируете это в режиме только для чтения, а поверх монтируете то, куда попадут все изменения. И раз в N времени перепаковывать все в основной снэпшот.
  • +1
    Спасибо за описание интересного опыта. Навело на мысли попробовать построить подобную систему на основе archboot wiki.archlinux.org/index.php/Archboot. Сам пользуюсь портативным арчом, установленном на флешке. Размещение системы в памяти радикально решило бы проблемы производительности. А персистентность можно было бы решить использованием второй флешки с обычной файловой системой.
  • +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 в системе. Потому запас для работы системы оставлять всё же нужно.
    • 0
      Если уж так тянет использовать tmpfs — OOM killer вообще благоразумно фактически отключать, запрещая overcommit в 0, иначе поведение системы будет совершенно непредсказуемое.
  • +2
    А мог бы автор написать подобную статью, но для Windows?

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

    Было бы прекрасно придумать варианты, как на рамдиске держать tmp/system32/config и другие папки, в которые вин все время что-то пишет. Это скорее связано даже не столько с ускорением работы, сколько с минимизацией обращения к SSD на тему записи.
    • +2
      Мне нужна подсказка, является ли нарушением лицензионного соглашения Windows удаление пакетов из дистрибутива встроенным менеджером пакетов dism. Потому что если является, то такую статью воспрещено публиковать.
      • 0
        Удаляйте на здоровье, там ничего сложного нет. Тем более для схем RDP Farm/VDI, когда в системах клиентов не должно быть ничего лишнего.
        Я то знаю, как это делать, а для новичков — думаю было бы интересно, а вот кейс применения — каждому свое
        • 0
          Ну действительно, тонкие клиенты, киоски… Если не запрещено это делать, то напишу. Помнится, я был в полном восторге от того, что 8.1 Pro можно уместить в 2.7 Гб.
          • 0
            Не запрещено, нет. По крайней мере, в ГК РФ точно сказано, что обладатель лицензии на продукт может его как угодно изменять, в РБ скорее всего так же.
            • +1
              в ГК РФ точно сказано, что обладатель лицензии на продукт может его как угодно изменять

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

              осуществлять действия, необходимые для функционирования программы для ЭВМ или базы данных (в том числе в ходе использования в соответствии с их назначением), включая запись и хранение в памяти ЭВМ (одной ЭВМ или одного пользователя сети), внесение в программу для ЭВМ или базу данных изменений исключительно в целях их функционирования на технических средствах пользователя, исправление явных ошибок, если иное не предусмотрено договором с правообладателем;
    • 0
      Хотя… если поставить 32 Гб RAM, то можно не модифицировать дистрибутив Windows. Она поместится.
      Но сама технология Windows в RAM очень простая, не уверен, что наберется на статью…
      • 0
        Может тогда поделитесь ссылкой где об этом можно почитать?
        • 0
          ну серьезно, гуглится же за 3 секунды: geektimes.ru/post/185172/
          • 0
            Ну вот, уже все написано, значит нужды писать еще одну статью нет.
            • 0
              berezuev, спасибо и плюсик.
              aokoroko, опишите пожалуйста про пакеты, какие можно удалять и как найти нужный (как то возился с языковыми пакетами, и помню тот ужас который меня охватывал от этого не юзерфрендли способа установки\удаления)
          • 0
            Отправил в избранное. Спасибо.
        • 0
          Мне не попадалась толковая статья, где все было бы собрано в одном месте, поэтому, думаю, все же напишу. Ключевые компоненты, которые нужны, — это загрузчик grub4dos и драйвер его рамдиска firadisk. Загрузчик китайских разработчиков и про него пишут, но как-то фрагментарно и многое устарело. Официальный сайт у него grub4dos.chenall.net/
          Драйвер разработал Karyonix и оригинал выложен тут: reboot.pro/topic/8804-firadisk-latest-00130/
  • +2
    300к IOPS не так уж много. У меня в лабораториях пачка SSD выдаёт больше. Из чего можно сделать вывод, что в сегодняшних реалях tmpfs — не самая быстрая система. Так же как и rbd (ram block disk). Увы. Плюс, на tmpfs нет очереди, так что в некоторых ситуациях некоторые типы нагрузки (с резкими всплесками) будут даже медленее.

    Это не ssd такие быстрые, это tmpfs такая медленная.
    • +2
      Ну… пачка SSD. Сравнили. Думаю что пачка многоканальной памяти и рейд из опративок вполне могут потягаться в разы.

      Причем вы смотрите. у него IOPS на домашней недорогой машине на уровне вашей пачки SSD скорее всего в 10-100 раз дороже суммарно по стоимости его оперативки.
      • +1
        Я не про то, что 'Пачка SSD круто', а про то, что tmpfs медленный. У меня на столе ноутбук трёхлетней давности — он выдаёт 50к IOPS. Рамдиск выдаёт 300к. Не чувствуете дискомфорта?
        • 0
          Конечно, я согласен, что есть аппаратные решения с бОльшим быстродействием. Например, PCIe SSD и InfiniBand Flash/DRAM, но таки моя статья про недорогую домашнюю систему и чисто программное решение, простое. Да, значение IOPS меня несколько огорчило, ожидалось больше. Однако латентность радует, 0.29 микросекунд.
          • +1
            Кстати, не срастается. Если iodepth=1, то при 1.99 µs (вы не туда смотрите), должно быть 502к IOPS, а не 390к. 1/0.00000199=502512
            • 0
              В чем же причина? Параметры запуска у меня в командной строке — можете посмотреть. А почему не туда смотрю? В руководствах советуют сравнивать именно clat…
        • 0
          tmpfs медленный. У меня на столе ноутбук трёхлетней давности — он выдаёт 50к IOPS. Рамдиск выдаёт 300к.

          Какой смысл сравнивать файловую систему с блочным устройством?
          • +1
            Файловая система близка к производительности к дисковой. Если положить файл на файловую систему и сделать ио на неё, разницы будет почти никакой.
            • 0
              А, я понял, 300к — с brd, а 50к — с диска, а не с tmpfs. Ok.
    • +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ГБ оперативки, хотя на самом деле это не так.
      • 0
        3.16.0-4
        Побудило на эксперимент то, что сколько разных LiveCD с squashfs я не перепробовал, скорость запуска приложений не удовлетворила. Она была меньше, чем видно в скринкасте в конце статьи.
        А эта особенность tmpfs разве не исправлена?
        • 0
          А эта особенность tmpfs разве не исправлена?
          Нет, насколько мне известно. Можно только смотреть реальную занятость памяти через /proc/meminfo.
          • 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

            и получил такой результат:
            image
            Т. е. я записал на tmpfs файл 3 Гб и free показывает, что свободной памяти стало на 3 Гб меньше, а занятой — больше. Кэши сбрасывал.
            • 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 %
  • +1
    Присоединяйтесь:
    en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM
    По мне, так самый интересный это: tinycorelinux.net

    Мое мнение, во всем этом нет смысла, выигрыш только при запуске, а не удобств полно.
    Главный tmpfs — временная Ф.С., ваш КО.
    Но для познавательных целей, конечно полезно.
    • 0
      Кроме запуска, выигрыш в отсутствии амортизации диска, а можно его вообще не иметь. Еще выигрыш в возможности отката всех изменений просто нажатием Reset. Последнее актуально, когда есть мамы-бабушки, ставящие «вход в интернет» и дети.
      • 0
        Бабушки будут ходить в интернет из системы, в которой не предусмотрено обновление хотя бы браузера. Я бы поостерегся.
        • –2
          Так sudo apt-get update && sudo apt-get upgrade же при старте ну и потом периодически…
  • –1
    А через overlayfs такое не сотворить?
    • 0
      Это, как я понял, замена UnionFS. Значит оно поможет сохранять изменения в другое место.
  • +1
    Что-то я не понял, чем это лучше стандартной initramfs?
    Берём нужную нам корневую файловую систему, заворачиваем её в cpio и даём грубу в параметре initrd. Всё.
    • 0
      Я про это тоже думал, но мне тут не хватает знаний. Нужны ли какие-либо драйверы? Как это сделать в деталях? Буду благодарен, если распишете «для чайника». И чем будет в итоге это? Так и будет initramfs? Как она по производительности в сравнении с tmpfs? Рассчитана ли она на многогигабайтные размеры? Из линуксов «целиком в initrd» я видел только Damn Small Linux с initrd размером 50 Мб.
      • +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.
        • 0
          Спасибо! Попробую сделать, позже отпишусь.
        • 0
          Поставил опыт. Увы, вот так просто «в лоб» не работает. Initramfs читается и распаковывается, но затем Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
          • 0
            Обязательно нужен либо /init в корне, либо параметр ядра rdinit=… Ну и могут быть тонкости, в зависимости от того, как сделан /dev.
  • 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

    • 0
      Диски — не SSD если что…
    • 0
      Тест fio по рандомной записи делал, а не приложил, потому что он принципиально не отличается. Вот скриншот randwrite: ccosplay.com/fio-randwrite.jpg
      Тесты с dd я не соглашусь, что полностью бессмысленны. Задача последовательного чтения или записи большого файла часто встречается. В статьях о некорректности dd указывают на то, что он может не учитывать кэширование, но в данном случае кэширования нет — tmpfs не кэшируется вовсе. Собственно, копирование больших (несколько Гб) файлов в консоли или mc показывает те же результаты, что и dd, и информация о скорости этого копирования не бесполезна.
      15.2 — это милли- или микросекунд? ms обычно обозначаются миллисекунды…
      • 0
        15.2 микросекунд (usec), ошибся, пардон…
        • 0
          Ну вот, а у меня 0.29 usec, что в 50 раз меньше. По идее, это должно влиять на отзывчивость системы в лучшую сторону…
          • 0
            Вообще в случае RAM-хранилищ нужно мерять по lat (у меня он порядка 17 us, у вас — 2 us), т.к. slat кхм… существенно выше clat :) тогда разница получается в 10 раз. Но с точки зрения пользователя с SATA диском (iops ~300 и lat 7000 us) — разница между tmpfs и ZFS несущественна в производительности, зато по набору опций… даже несравнимо.
    • 0
      По-моему, размер файла для теста у вас очень маленький. Эти 2ГБ полностью влазят в ARC и, естественно, отсюда такое большое значение IOPs.
      • 0
        Ну, как бы у автора tmpfs тоже влазит в RAM целиком. Я лишь хотел показать, что с достаточно большим объемом RAM и дешевыми HDD, ZFS является вполне себе достойной альетративой SSD и tmpfs.
  • 0
    Еще бы execute-in-place приделать — и будет совсем хорошо.
  • 0
    По-оему, обычного SSD вполне достаточно для обеспечения практически необходимого быстродействия.
    Ну какая разница сколько грузится linux, если на нормальных серверах время старта самого сервера до операционной системы изменяется в минутах. А на ноутбуках, где с диском как раз беда, оперативной памяти много не бывает.

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

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

        Те само приложение будет работать с каким то файлами, если они не нужны то их можно вытащить на tmpfs, а если нужны то проще оставить на диске. Тут уже от конкретных условий зависит.
        • 0
          /tmp и так в tmpfs, судя по дефолтном fstab. Kubuntu 14.04.
  • 0
    Спортивного интереса ради оно хорошо.

    На практике даже не знаю, с SSD скорость не так чтобы сильно должна различаться, ведь при загрузке вторым узким местом является инициализация, как устройств так и программ. В первом случае бывают вообще sleep()/delay() в коде, во втором дикая нагрузка на проц.
    Ну и поддерживать систему с SSD на порядок проще.
  • +1
    А какая у вас память используется?
    Я прогнал у себя на рабочем сервере (там тоже tmpfs создан для некоторыз проектов):
    Скрытый текст
    image
    • +1
      DDR3 Kingston 1333 МГц 2x8 Гб (CPU Sandy Bridge i5 2310 2.9 ГГц), одним словом, домашняя машинка. Надо полагагать, на сервере с высокочастотной / многоканальной памятью будет гораздо больше IOPS, что у вас и видим.
  • +1
    На практике можно tmpfs применять и не столь радикально для увеличения нагрузочной способности, если ресурсы ограничены. Довелось как-то сооружать Web-сервер, с которого через канал 100 МБит/с иногда весьма активно скачиваются файлы объёмом примерно от 30 до 150 МБайт. В машинке, отведённой под этот сервер, был только один отсек для жёсткого диска (да и то 2,5 дюйма), и были сомнения насчёт работы сервера под нагрузкой, но зато можно было поставить довольно много ОЗУ, и появился резон читать файлы под скачивание не с диска, а из памяти. Накатил на этот диск Linux, в качестве Web-сервера поставил nginx, а Web-каталог ему сделал в tmpfs. При загрузке ОС скрипт автозапуска до старта nginx готовит файловую систему, в ней делает Web-каталог и копирует туда с жёсткого диска файлы под скачивание. Другой скрипт, запускаемый по cron, периодически сверяет содержимое эталонного каталога на жёстком диске с каталогом в tmpfs и обновляет файлы в Web-каталоге при обновлении таковых в эталоне. В итоге цели поднятия этого сервера были достигнуты; машинка держит нагрузку с приличным запасом; думаю, при необходимости можно будет скорость канала ещё в несколько раз увеличить.
  • 0
    Господа, простите, ночь, может я туплю… А что если так:
    — берем любой линкус
    — выдаляем tmpfs раздел на нужное количество гигов
    — ставим виртуальную машину с любой желаемой ОС
    — размещаем файлы виртуалки на tmpfs
    — запускаем, работаем, обновляем ОС, ставим программки
    — выключаем
    — синкаем файлы с tmpfs на любой персистентный носитель
    — profit?

    Ну да, будет просадочка на виртуализацию, но на современном железе она минимальна. Зато плюсы какие. Не? Попробуйте кто-нибудь? :)
    • 0
      Ну в принципе хорошая мысль. Только я опасаюсь, что на домашнем железе не хватит оперативной памяти, если в виртуальную машину ставить Windows x64. Зело она велика по объему, особенно при обновлении много Гб требуется. А если на нее еще MS Office поставить, то тем более.
  • +1
    А ГИМП даже на рамдиске грузится дольше всех…
    • 0
      Да, он такой. Написан он так. Что поделать.
      • 0
        НЕ использовать ГИМП?
        • 0
          А использовать что?
          • 0
            Krita хвалят
  • 0
  • 0
    Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.

    Если не сложно, опишите более подробно — как это у Вас реализовано.
    • 0
      Выше дали ссылку geektimes.ru/post/185172/
      Оказывается, уже написали до меня. Но там большая статья, у меня несколько проще, хотя основа та же — grub4dos и firadisk.
  • +1
    Во-первых, статья решительно ни о чем. Человек открыл для себя tmpfs. Поздравляю, он существует уже лет 27 вообще и около 14 лет в линуксе.
    Во-вторых, для Вашего сценария достаточно весь образ системы засунуть в initramfs: начиная с ядер 2.6, если в ядре есть tmpfs, то rootfs — это tmpfs (если не указано иное в параметрах ядра) — см. www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt Ради чего делать вторую tmpfs поверх — непонятно.
    • –1
      Я обещаю поставить опыт с initramfs. Если всё так, то это здорово упрощает дело и статья действительно становится праздной. Но все же у меня есть сомнения, что все пройдет гладко. И нужна ли правка fstab в этом случае?
    • –1
      Поставил опыт. Увы, вот так просто «в лоб» не работает. Initramfs читается и распаковывается, но затем Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
      Видимо, нужны некторые ключевые детали, о которых вы не упомянули…
      • +1
        По ссылке же все написано… ядро ищет init в корне initramfs, а у Вас он в /sbin/init. Сделайте симлинк или передайте ядру параметр rdinit=/sbin/init. Не забудьте убрать / из fstab, а то у Вас все посыплется на попытке fsck.
  • 0
    В systemd прилетел коммит, который позволяет делать точно то же, что описывает автор, стандартными средствами.
    www.phoronix.com/scan.php?page=news_item&px=Systemd-Stateless-Root
    • 0
      Я вижу только fstab генератор для root on tmpfs, а остальное как? Всё в initramfs.cpio.gz?
      • 0
        Да.
        • 0
          Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
          Пробовал и со своим fstab, и с пустым — то же самое. Ядро пытается монтировать root fs на блочное устройство???
          • 0
            ИМХО это переводится как «Невозможно монтировать rootfs, расположенную на блочном устройстве».

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

    • способы этого достичь
      • монтировать надежную fs в read-only
      • squashfs
      • tmpfs
      • другое

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


    Мне непонятно, чего хотел добиться автор, и почему его решение хорошее. Запускать LibreOffice за 0.5 c вместо 1 с? Так никто обычно не запускает тяжелые программы, чтобы сразу из них выйти. Ну и полноте жаловаться, на SSD все и так запускается достаточно быстро.
    • 0
      После запуска программы разве она больше не производит дисковых операций? Еще как производит. SSD и кэширование придумали именно для этого. Однако можно и быстрее, что я и продемонстрировал. Я реально в такой системе работаю (как в Linux, так и в Windows), и ни за какие коврижки не соглашусь обратно на HDD и даже на SSD. Потому что медленно. Ну и на одной из работ критично, смогу я открыть и исследовать, например, 1000 веб-страниц за 8 часов или же за 5 часов, потому что это нужно делать ежедневно, и когда узкое место — моя собственная производительность, то это одно, а когда подтормаживает машина, то это очень печалит и вынимает з/п из кошелька и уменьшает время на отдых.
      • 0
        Я не знаю точно, как устроен firefox, но не уверен, что файловая система на tmpfs ускоряет открывание 1000 вкладок. Первый запуск, возможно. Но открытые страницы firefox хранит не на диске, а в памяти, которую вы у него забрали. В любом случае, возможно, достаточно было бы перенсти профиль firefox на tmpfs.
    • +3
      У вас личная неприязнь к автору? Это уже второй коммент с общей мыслью «не знаю зачем эта ваша initrd-only ОС, у кого-то избыток свободного времени, у меня на SSD всё работает с той же скоростью.» Высокомерие — плохая черта. Статья нужна потому, что она демонстрирует, что можно поместить ОС за пару простых действий целиком в память. Это как минимум стимулирует тех читателей, кто раньше не знал / не задумывался о такой возможности, глубже познакомиться с устройством init в дебиане, с initramfs/unionfs, задуматься о плюсах переноса какого-нибудь содержимого с харда на виртуальный диск. Люди разные, машины и задачи у них разные, у кого-то SSD, у кого-то HDD, у кого-то бездисковый тонкий клиент. В комментах выше пару кейсов привели, когда initrd нужен.
      • +1
        Это не высокомерие. Удивлен, что столько внимание привлекла статья, которая не рассматривает ни альтернативные решения, нет никаких сравнений производительности (я вот не уверен, что производительность в целом выше, так как производительность — это не только скорость запуска firefox), надежности, совершенно не продуманы вопросы обновления.

        Автор описал только два преимущества:
        — быстро запускаются приложения (что, в общем, не так уж важно при реальной работе)
        — можно выключать/перезагружать компьютер в любой момент (что, в общем, тоже не особо необходимо в обычной работе, так как ничто не мешает выполнять полноценный shutdown)
        • 0
          Прошу прощения, но это применительно к подобной стстеме для Windows они не продуманы, а эта статья о Linux. apt-get update && apt-get upgrade после старта ведь решает вопрос обновления, разве нет?
      • 0
        Поддержу комментатора immaculate.

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

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

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

        Это я про винду.
        В линуксе же есть, например, anything-sync-daemon, который любую папку пихает в рам и как положено там всё rsync'ает. Не нужно изобретать велосипеды, всё до нас уже изобрели. Это всё интересно исключительно для собственного развития: понять как оно там работает, поковырять, разобраться, допереть, что уже давно кем-то реализовано лучше, и воспользоваться готовым решением.
        • 0
          Теперь представим ситуацию: у вас над ухом стоит начальник, который с делегацией, и вам нужно очень быстро показать ему что-то. Вы запускаете это что-то и… именно в этот момент в кэше этого нет, в рам были отправлены другие папки, произошло еще что-то, и т. д. и т. п. Начальник ждет ровно 3 секунды и идет дальше с делегацией, вы не получили ничего. Я утрирую, но общий смысл в том, что если в системе есть медленные устройства, то это обязательно так или иначе будет сказываться. Я бы хотел, чтобы об этом вообще думали, искали новые решения, а не довольствовались тем, что уже изобретено. Да, данный способ имеет недостатки. Придумайте лучший, еще более быстрый, без недостатков, может быть, вообще аппаратный, чтобы при помощи паяльника каждый мог сделать у себя дома.
          • 0
            В большинстве систем даже с SSD самым медленным устройством оказывается процессор, т. к. ввод-вывод начинает упираться именно в него, в постоянную смену контекста потоков, промахи кеша, миллионы неоптимальных сисколов без scatter-gather и т. д. Все эти тесты слишком синтетичны и не отражают реалий современного быдлокодерства. Тот же Экслипс хоть на марсоходе запускай, меньше, чем за 4-5 секунд он не стартует без тонкой настройки.

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

            Я абсолютно не против поиска подобных костылей, сам раньше позволял себе копаться в чём-то, досконально разбираться, а сейчас пришло понимание, что лучше потратить в 10 раз меньше времени, воспользоваться готовым решением, и потерять максимум 20% производительности.
            • 0
              Как человек, в 2015 году пишущий оконные приложения для Win 8.1 x86 на ассемблере, вполне соглашусь с первым абзацем.
              • 0
                О! С этого и надо было начинать статью. Я бы не стал тратить время на комментирование. :)
                • –2
                  А узнав, что Алан Тьюринг был геем, вы бы стали читать его труды по логике? Вы считаете, что его ориентация ухудшила качество его работ? А шизофрения Джона Нэша — ухудшила качество его математических работ? Или, может быть, язык ассемблера — это что-то, что хуже педерастии и шизофрении?
                  • +3
                    Вы очень лично все восприняли, мне жаль. А я не осуждаю, но и не одобряю. Я просто оптимизирую жизнь, программы, системы по другому принципу. С моей точки зрения, считать такты на ассемблере бессмысленно, потому что пока я буду их считать, поезд уже уйдет, и программа будет не нужна ни мне, ни кому-либо другому. Ложка дорога к обеду.

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

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

                    В общем, нет у меня ни высокомерия, ни осуждения. Какая-то эмоция впрочем есть, потому что все же в нескольких комментариях отметился.
                    • –1
                      Вы осуждаете, и не просто, а именно «не читал, но осуждаю» (с), потому что не изучаете и не тестируете, а «без бенчмарков мне кажется». И здесь не пара лошадиных сил, а по ряду параметров разница на порядок с SSD и на несколько порядков с HDD.
                      Написание программ на ассемблере не занимает больше времени, чем на любом другом языке, и не является более сложным и трудоемким, чем на любом другом языке.
                  • –1
                    Таки Алан Тьюринг был педофилом, разве нет?
                    • +1
                      Таки нет, лечили его именно от гомосексуализма. Про педофилию никогда не слышал.
                  • 0
                    Ну если бы Алан Тьюринг высказал своё мнение о том, что мужчины во всех отношениях красивее и привлекательнее женщин, я бы не стал прислушиваться к его мнению.
    • 0
      Мне непонятно, чего хотел добиться автор, и почему его решение хорошее. Запускать LibreOffice за 0.5 c вместо 1 с? Так никто обычно не запускает тяжелые программы, чтобы сразу из них выйти. Ну и полноте жаловаться, на SSD все и так запускается достаточно быстро.

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

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

    P.S. А в гибернацию такая система ляжет? ;)
    • 0
      Гибернацию не проверял, так как все системники работают 24/7. Скорее всего, да, при наличии достаточно RAM.
      • +1
        RAM — это Suspend, а гибернация на диск делается. Впрочем не вижу никакой причины не работать гибернации, только своп для этого нужен большой.
        • 0
          STR — Suspend to RAM, STD — Suspend to Disk или они нынче больше не работают?
          • +1
            Не совсем понял, о чем Вы. Я же о том, что Гибернацией (как правило) называют Suspend to Disk. Т.е. сбрасывание всей памяти на диск (в Линуксе это, как правило своп) и отключение питания процессора и памяти.
            А Suspend to RAM часто (так скажем раньше) просто называют Suspend, т.е просто приостановка всех приложений и перевод процессора в спящий режим.
            Если я ничего не напутал, то исходя из этого большое количество RAM совершенно не нужно для гибернации, а даже наоборот — несколько вредно.
            • 0
              Я только процитировал термины энергосберегающих режимов, что они оба Suspend :).

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