Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 167
habrahabr.ru/post/164147/
вы можете возразить, что появятся оверхед от squashfs, но по факту это не заметно.
вы можете возразить, что появятся оверхед от squashfs, но по факту это не заметно.
Как вы решаете проблему, если нужно что-то доустановить или изменить конфигурацию?
Каждый раз целиком пересоздаете ram.tar.gz?
Я давно хотел сделать что-то подобное для Windows и SSD, чтобы система свои постоянные обращения к диску делала в рамдрайв, и только пару раз в день скидывала изменения на SSD. И быстро и срок службы продлевается. Но эту задачу решить не удалось. Инструменты типа рамдрайв скидывают только полный дамп на диск…
Каждый раз целиком пересоздаете ram.tar.gz?
Я давно хотел сделать что-то подобное для Windows и SSD, чтобы система свои постоянные обращения к диску делала в рамдрайв, и только пару раз в день скидывала изменения на SSD. И быстро и срок службы продлевается. Но эту задачу решить не удалось. Инструменты типа рамдрайв скидывают только полный дамп на диск…
Я тут так подумал, что можно попробовать таки хранить в полноценном разделе всё, из него всё и копировать в tmpfs, и заскриптить при помощи inotify сбрасывание обратно, но там достаточно много скорее всего особенностей.
У меня, кроме производительности, была еще цель создать неубиваемую систему, поэтому изменение архива никак не автоматизировано, оно делается редко, вручную, сразу после перезагрузки, вносятся необходимые изменения и делается новый архив. Такие предосторожности, чтобы не доустановить что-нибудь плохое. Но это если накопилось много претензий и хочется переделать. А так вообще в дебиане очень просто что-то доустановить из репозитория. Можно неделю, месяц работать не перезагружая систему, делать с ней все, что заблагорассудится, ставить софт и т. д. Единственно, конечно, объем установленной RAM ограничивает.
В puppyrus была подобная система. Там есть основной образ системы + squashfs архив с изменениями. Причем насколько я помню, там можно настроить так, чтобы все файлы загрузились в оперативку и чтение было с нее, а например через какие то периоды времени в фоне данные синхронизировались с squashfs. Или при выключении можно сохранить не помню.
И там гибкость была в том, что можно было создать несколько squashfs архивов с различными конфигурациями, и грузить их если что либо необходимо. Можно было на 2х гигах оперативы загружать к примеру либо образ для работы с графикой, а потом быстро переключаться на образ для игр, или например образ для разработки с различными IDE.
И там гибкость была в том, что можно было создать несколько squashfs архивов с различными конфигурациями, и грузить их если что либо необходимо. Можно было на 2х гигах оперативы загружать к примеру либо образ для работы с графикой, а потом быстро переключаться на образ для игр, или например образ для разработки с различными IDE.
Угу, я слежу за puppyrus, он развивается, вот свежий, построенный на Арче: PuppyRus-A
А обновления как? Каждый раз при загрузке системы?
У меня три года рабочие станции жили на EWF — как раз то что вам нужно: habrahabr.ru/company/pt/blog/155135/
Что-то очень похожее на LVM
Там ФС живёт на диске, изменения кэшируются в оперативке и при перезагрузке херятся. Если нужно внести изменения в ФС, просто пинаешь специальный батник и тогда при перезагрузке или выключении машины кэш сбрасывается на диск. Очень помогало от криворуких пользователей и вирусняков. Все проблемы решались перезагрузкой. Одно неудобство было только при установке тяжёлого софта. Например на машине с 512Гб оперативки не получалось вкатать OpenOffice т.к. он при установке записывал на диск больше данных, чем умещалось в оперативке. Самым активным юзерам делали апгрейды до 1-2Гб, но 70% народу сидело на 512Мб вполне комфортно.
Очень круто. Как раз памяти много. Вы можете пояснить как данные сохраняются? например, я обновил софт или новый поставил. Я упустил этот момент. Плюс home раздел на ssd и в tmpfs не заливается, наскрлько я понимаю.
Да никак не делается. Автор сначала обругал squashfs (он якобы медленный — но скромно умолчав о том, сколько занимает зачитывание и распаковка всего тарболла разом с носителя в tmpfs), потом второй раз обругал squashfs (якобы там сложная многослойная система монтирования) — но в предложенном варианте все эти «проблемы» с persistency просто игнорируются — всё живет до тех пор, пока есть питание и жива система.
Да, согласен, у меня нет никакого persistency, зато можно безопасно экспериментировать, не боясь убить систему. Это, можно так сказать, не баг, а фича, что после перезагрузки происходит фактически откат ОС на эталонный образ — так было задумано ради безопасности.
Тарболл у меня вышел около 600 Мб, зачитывание и распаковка его происходит быстро. Да и не очень это критично делать раз в день…
Тарболл у меня вышел около 600 Мб, зачитывание и распаковка его происходит быстро. Да и не очень это критично делать раз в день…
Не монтировать по умолчанию файловые системы с постоянного носителя (а он у вас по любому же есть — вы же не из сети тарболл берете) — это гигантский прорыв в области безопасности, да…
Да ещё и после перезагрузки автор получает систему без обновлений безопасности.
Но ведь произвести несанкционированные изменения файлов внутри архива на рид-онли носителе практически невозможно, в отличие от файловой системы на обычном носителе. В течение некоторого времени после загрузки мы можем быть уверены в «чистоте» системы. Я ошибаюсь?
Мне очень нравятся «практически невозможно» и «в течение некоторого времени мы может быть уверены» :) Это как «немножко беременна».
Если у вас только не аппаратно защищенный носитель (а вы говорили о флешках, HDD и SSD), имея в системе рута, никто не запретит malware замонтировать этот носитель в read-write, распаковать этот самый архив, сделать изменения и перепаковать его вновь. Не говоря уже о том, что ядро у вас как грузилось с этого носителя, так и грузится. Руткиты для фактически любых ядер сейчас доступны каждому.
«Некоторое время», при условии наличия в сети активного атакующего со свежим remote root exploit'ом, будет стремиться к нулю. За примерами даже далеко ходить не надо — DHCP-сервер злоумышленника с ответами специального вида + Shellshock + достаточно старый dhclient / dhcpcd = исполнение произвольного кода из под root еще на этапе загрузки системы и получения IP-адреса.
Если у вас только не аппаратно защищенный носитель (а вы говорили о флешках, HDD и SSD), имея в системе рута, никто не запретит malware замонтировать этот носитель в read-write, распаковать этот самый архив, сделать изменения и перепаковать его вновь. Не говоря уже о том, что ядро у вас как грузилось с этого носителя, так и грузится. Руткиты для фактически любых ядер сейчас доступны каждому.
«Некоторое время», при условии наличия в сети активного атакующего со свежим remote root exploit'ом, будет стремиться к нулю. За примерами даже далеко ходить не надо — DHCP-сервер злоумышленника с ответами специального вида + Shellshock + достаточно старый dhclient / dhcpcd = исполнение произвольного кода из под root еще на этапе загрузки системы и получения IP-адреса.
Упомянутый тарболл хранится также на CD-R и на флешках, контроллер которых перепрограммирован и представляется CD диском, то есть аппаратно read-only. Если на read-write носителях он будет перепакован, то я это замечу по изменению его контрольных сумм?
Если у вас есть внешняя сущность, с которой сравнивать (контрольные ли суммы или сами файлы) и сам процесс сравнения — то, разумеется, заметите. Если это не внешняя сущность, то никто не мешает malware модифицировать процесс сравнения так, чтобы он показывал, что все хорошо, когда на деле руткит будет внедрен.
Впрочем, все это уже относится к области работы IDSов и антивирусов — там уже до нас с вами накоплены многие годы опыта и придумана масса вещей. И в этом месте «обычный компьютер + IDS или антивирус» как бы не будет толком ничем отличаться от «компьютер с tmpfs root + IDS или антивирус».
Впрочем, все это уже относится к области работы IDSов и антивирусов — там уже до нас с вами накоплены многие годы опыта и придумана масса вещей. И в этом месте «обычный компьютер + IDS или антивирус» как бы не будет толком ничем отличаться от «компьютер с tmpfs root + IDS или антивирус».
Когда я ставил Debian с нуля, поставил ВСЁ в один раздел. Т. е. /home тоже архивируется в образ для рам-загрузки.
Обновления да, не сохраняются. Данные, с которыми работаю, сохраняю на те носители, что есть — флешки, облака, HDD есть в компе не один…
Обновления да, не сохраняются. Данные, с которыми работаю, сохраняю на те носители, что есть — флешки, облака, HDD есть в компе не один…
Кстати, заодно хочу спросить — никто не знает как более агрессивно усилить кэширование? Память простаивает) стоит preload.
Я думаю, что все кэшируется и так максимально оптимально. Такие «вопросы» и «руководства» появляются, когда у человека мало реальных задач и много свободного времени.
Когда решаешь реальные задачи, это не имеет значения. У меня ноутбук с SSD. Я начинаю работу с того, что запускаю основные свои инструменты: консоль, Firefox, и PyCharm. Когда заканчиваю день, закрываю ноутбук и он уходит в suspend. То есть, один раз я может быть жду 1,5 секунды пока загрузится Firefox с SSD, но это терпимо, так как это и так очень небольшое время, и запускается он не чаще одного раза в две недели, а то и больше.
На горождении костылей с tmpfs/squashfs я бы потерял в разы больше времени, а так же наверняка потерял бы не раз несохраненную работу, что еще хуже.
Когда решаешь реальные задачи, это не имеет значения. У меня ноутбук с SSD. Я начинаю работу с того, что запускаю основные свои инструменты: консоль, Firefox, и PyCharm. Когда заканчиваю день, закрываю ноутбук и он уходит в suspend. То есть, один раз я может быть жду 1,5 секунды пока загрузится Firefox с SSD, но это терпимо, так как это и так очень небольшое время, и запускается он не чаще одного раза в две недели, а то и больше.
На горождении костылей с tmpfs/squashfs я бы потерял в разы больше времени, а так же наверняка потерял бы не раз несохраненную работу, что еще хуже.
А у вас своп-файл включен? Попробуйте отключить — нагрузка на память возрастет, снизятся затраты времени на своп. Когда на компьютере было достаточно памяти (с WinXP), я именно так и работал. Значительно повышается производительность.
Что такое «усилить кэширование»? Где? В linux практически любое обращение к диску прозрачно кэшируется VFS'ом, выделяя под это дело всю свободную в данный момент память. Упрощенно. Так что в линуксе память не простаивает, не думайте, что вы один об этом подумали =)
А swap выключен?
Расскажите, как вы втиснули Windows в 16 ГБ.
Или у вас там XP?
Или у вас там XP?
Да, сколько у Автора было оперативки?
Вопрос хороший.
Сейчас у меня:
C:\Windows\ 32GB;
C:\ProgramData\ 23GB;
C:\Program Files\ 12GB;
C:\Program Files (x86)\ 19GB.
итого 87 GB.
Сразу после установки Win 8.1 x86 на диске C: было занято 2.7 Гб, после установки нужного мне софта стало занято 4 Гб. Дело в том, что использовался подготовленный дистрибутив. Нет, не скачанный где-то в сети, а сделанный самостоятельно из оригинала Microsoft без использования каких-либо программ «для урезания» (которых сейчас развелось много), а только с помощью dism и regedit.
Вот я не знаю, подскажите, не будет ли против правил написать об этом статью на Хабр? Вроде бы Microsoft не разрешает производить подобные манипуляции со своими дистрибутивами?
Вот я не знаю, подскажите, не будет ли против правил написать об этом статью на Хабр? Вроде бы Microsoft не разрешает производить подобные манипуляции со своими дистрибутивами?
Политику MS не подскажу.
Но конфигурация ОС вполне в духе Хабра.
Однако, дюже любопытно, куда предусмотреть обновления (и резерв на откат), которые растут из недели в неделю. Не уж то целевая конфигурация «для школьного кабинета информатики; моей бабушке» высвобождает такие резервы по оптимизации размеров?
В отличие от Linux, обновления Windows обычно требуют перезагрузки, так что Windows на рам-диске не обновить никак. Чтобы обновить, понадобится ее грузить обычным способом. Но есть удобная технология от M$ — VHD диск. Его можно грузить обычным способом для настройки, обновления и т. д. и в RAM для быстрой работы.
Если не решитесь на статью — то накидайте ходя бы примерное направление куда гуглить, что починать.
Строго говоря Program Files — не совсем операционка. У меня стоит семерка установленная еще в 2009. Изначально занимала около 15Гб, а сейчас раздулась до примерно 25 (в основном за счет winsxs, у которго как-то туго с чисткой хлама)
8 октября 2013 года вышло рекомендуемое обновление KB2852386 для Windows 7 SP1 support.microsoft.com/kb/2852386. Оно добавляет функцию очистки WinSxS в утилиту «Очистка диска»
Работает не так хорошо, как в восьмерке, но работает.
Работает не так хорошо, как в восьмерке, но работает.
У меня там Windows 8.1 и сейчас я пишу этот коммент в ней.
Вот как выглядит диск C:, который расположен в RAM:
Вот как выглядит диск C:, который расположен в RAM:
Тоже экспериментировал с системой в памяти — создавал виртуалку, жесткий диск которой полностью был в памяти — потрясно быстро работает… но столкнулся с проблемой сохранения изменений после обновления например — каждый раз экспортировать напрягало…
Кроме того — не совсем согласен с неубиваемостью — если выключат электричество или система наглухо зависнет — все изменения пропадут же?
Кроме того — не совсем согласен с неубиваемостью — если выключат электричество или система наглухо зависнет — все изменения пропадут же?
Под неубиваемостью скорее всего имелась в виду возможность любую поломку вылечить ресетом.
По поводу пропадания изменений: я бы не сказал, что прямо все изменения исчезают.
Они пропадают ровно по тому же принципу, как и в обычной системе на hdd: то, что было в памяти — пропадёт, то, что было на hdd/nfs/samba/… — не пропадёт. Т.е. никто не мешает, например, загрузить ОС в память, как делает автор, затем примонтировать HDD или NFS шару и редактировать данные там.
Вы правы, если пропадет питание (UPS поможет) или зависнет наглухо (тут уже да, не поможет ничего), то пропадут изменения ОС. Но это, мне кажется, не очень страшно. Под неубиваемостью я имел в виду свойство неизменности тарболла. Если система наглухо зависнет, я нажму Reset на системнике и через минуту уже буду в неизмененной системе.
Мне кажется, если система наглухо виснет, надо решать проблему в железе или софте, который вызвал это зависание, а не городить черти-что на RAMDISK.
Вот у меня система никогда наглухо не виснет, поэтому я трачу свое время на решение реальных (ну, относительно) задач, таких как сделать рабочую задачу вовремя. Написать какой-нибудь план или отчет.
Мне не надо, чтобы у меня «тяжелые приложения» запускались со скоростью света. Во-первых, на SSD они и так настолько быстро запускаются, что едва замечаешь. Во-вторых, никто в реальной работе не использует карусель: запустил LibreOffice, тут же закрыл, затем Firefox, затем Gimp, затем Blender, затем Idea, все позакрывал и начал сначала.
Когда решаешь настоящие задачи, как правило, открываешь одно-два приложения, и работаешь в них. Поэтому мне вообще непонятна цель подобных извращений — не могу придумать workflow, в котором надо непрерывно открывать и закрывать тяжелые приложения.
Вот у меня система никогда наглухо не виснет, поэтому я трачу свое время на решение реальных (ну, относительно) задач, таких как сделать рабочую задачу вовремя. Написать какой-нибудь план или отчет.
Мне не надо, чтобы у меня «тяжелые приложения» запускались со скоростью света. Во-первых, на SSD они и так настолько быстро запускаются, что едва замечаешь. Во-вторых, никто в реальной работе не использует карусель: запустил LibreOffice, тут же закрыл, затем Firefox, затем Gimp, затем Blender, затем Idea, все позакрывал и начал сначала.
Когда решаешь настоящие задачи, как правило, открываешь одно-два приложения, и работаешь в них. Поэтому мне вообще непонятна цель подобных извращений — не могу придумать workflow, в котором надо непрерывно открывать и закрывать тяжелые приложения.
По вопросу «нагухо виснет» вы отвечайте, пожалуйста, не мне, а timerbulatov. У меня такой проблемы нет и статья не о решении проблем зависания. Также она не о RAMDISK, который есть блочное устройство. Ну и закрывать приложения не обязательно. На «черти» и «извращения» ответил в другом месте.
Скорость записи на SSD все же гораздо ниже, чем скорость записи на диск.
Я наглядно вижу, что firefox на Ramdisk живет быстрее чем на SSD. Вдобавок это как раз то, что чаще всего пишет ненужные (временные файлы) на диск. А к чувству «SSD не жалко» я только начал привыкать.
Даже начинаю думать, что надо покупать два SSD — большой для системы, и маленький но быстрый для всяких временных папок, кешей, свопа, на котором не будет лежать критической инфы вообще, и его уже менять по мере проблем.
Я наглядно вижу, что firefox на Ramdisk живет быстрее чем на SSD. Вдобавок это как раз то, что чаще всего пишет ненужные (временные файлы) на диск. А к чувству «SSD не жалко» я только начал привыкать.
Даже начинаю думать, что надо покупать два SSD — большой для системы, и маленький но быстрый для всяких временных папок, кешей, свопа, на котором не будет лежать критической инфы вообще, и его уже менять по мере проблем.
На счет изменений можно посмотреть в сторону UnionFS и ее аналогов (вроде в Linux в последнее время это все встроено в mount и ядро) т.е. вы как-то раз делаете снэпшот файловой системы в удобном для Вас виде (squashfs, tar.gz, etc..) монтируете это в режиме только для чтения, а поверх монтируете то, куда попадут все изменения. И раз в N времени перепаковывать все в основной снэпшот.
Спасибо за описание интересного опыта. Навело на мысли попробовать построить подобную систему на основе archboot wiki.archlinux.org/index.php/Archboot. Сам пользуюсь портативным арчом, установленном на флешке. Размещение системы в памяти радикально решило бы проблемы производительности. А персистентность можно было бы решить использованием второй флешки с обычной файловой системой.
Использую подобное решение с 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).
И ещё:
Использовать всю память под диск, слишком оптимистично. В случае недосмотра и переполнения диска рискуем получить OOMKiller в системе. Потому запас для работы системы оставлять всё же нужно.
Загрузка осуществляется с 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 в системе. Потому запас для работы системы оставлять всё же нужно.
А мог бы автор написать подобную статью, но для Windows?
Я сейчас использую ramdisk для самых необходимых приложений (far, firefox), и собственно больше всего напрягает именно периодическое сбрасывание рамдиска на жесткий диск. Компьютер не перегружаю месяцами, но чтобы ничего не потерять сброс настроил каждые сутки. И из-за него держу рамдиск минимального размера.
Было бы прекрасно придумать варианты, как на рамдиске держать tmp/system32/config и другие папки, в которые вин все время что-то пишет. Это скорее связано даже не столько с ускорением работы, сколько с минимизацией обращения к SSD на тему записи.
Я сейчас использую ramdisk для самых необходимых приложений (far, firefox), и собственно больше всего напрягает именно периодическое сбрасывание рамдиска на жесткий диск. Компьютер не перегружаю месяцами, но чтобы ничего не потерять сброс настроил каждые сутки. И из-за него держу рамдиск минимального размера.
Было бы прекрасно придумать варианты, как на рамдиске держать tmp/system32/config и другие папки, в которые вин все время что-то пишет. Это скорее связано даже не столько с ускорением работы, сколько с минимизацией обращения к SSD на тему записи.
Мне нужна подсказка, является ли нарушением лицензионного соглашения Windows удаление пакетов из дистрибутива встроенным менеджером пакетов dism. Потому что если является, то такую статью воспрещено публиковать.
Удаляйте на здоровье, там ничего сложного нет. Тем более для схем RDP Farm/VDI, когда в системах клиентов не должно быть ничего лишнего.
Я то знаю, как это делать, а для новичков — думаю было бы интересно, а вот кейс применения — каждому свое
Я то знаю, как это делать, а для новичков — думаю было бы интересно, а вот кейс применения — каждому свое
Ну действительно, тонкие клиенты, киоски… Если не запрещено это делать, то напишу. Помнится, я был в полном восторге от того, что 8.1 Pro можно уместить в 2.7 Гб.
Не запрещено, нет. По крайней мере, в ГК РФ точно сказано, что обладатель лицензии на продукт может его как угодно изменять, в РБ скорее всего так же.
в ГК РФ точно сказано, что обладатель лицензии на продукт может его как угодно изменять
Было сказано. Раньше. Теперь немного по-другому (ст. 1280 ГК РФ):
осуществлять действия, необходимые для функционирования программы для ЭВМ или базы данных (в том числе в ходе использования в соответствии с их назначением), включая запись и хранение в памяти ЭВМ (одной ЭВМ или одного пользователя сети), внесение в программу для ЭВМ или базу данных изменений исключительно в целях их функционирования на технических средствах пользователя, исправление явных ошибок, если иное не предусмотрено договором с правообладателем;
Хотя… если поставить 32 Гб RAM, то можно не модифицировать дистрибутив Windows. Она поместится.
Но сама технология Windows в RAM очень простая, не уверен, что наберется на статью…
Но сама технология Windows в RAM очень простая, не уверен, что наберется на статью…
Может тогда поделитесь ссылкой где об этом можно почитать?
ну серьезно, гуглится же за 3 секунды: geektimes.ru/post/185172/
Мне не попадалась толковая статья, где все было бы собрано в одном месте, поэтому, думаю, все же напишу. Ключевые компоненты, которые нужны, — это загрузчик grub4dos и драйвер его рамдиска firadisk. Загрузчик китайских разработчиков и про него пишут, но как-то фрагментарно и многое устарело. Официальный сайт у него grub4dos.chenall.net/
Драйвер разработал Karyonix и оригинал выложен тут: reboot.pro/topic/8804-firadisk-latest-00130/
Драйвер разработал Karyonix и оригинал выложен тут: reboot.pro/topic/8804-firadisk-latest-00130/
300к IOPS не так уж много. У меня в лабораториях пачка SSD выдаёт больше. Из чего можно сделать вывод, что в сегодняшних реалях tmpfs — не самая быстрая система. Так же как и rbd (ram block disk). Увы. Плюс, на tmpfs нет очереди, так что в некоторых ситуациях некоторые типы нагрузки (с резкими всплесками) будут даже медленее.
Это не ssd такие быстрые, это tmpfs такая медленная.
Это не ssd такие быстрые, это tmpfs такая медленная.
Ну… пачка SSD. Сравнили. Думаю что пачка многоканальной памяти и рейд из опративок вполне могут потягаться в разы.
Причем вы смотрите. у него IOPS на домашней недорогой машине на уровне вашей пачки SSD скорее всего в 10-100 раз дороже суммарно по стоимости его оперативки.
Причем вы смотрите. у него IOPS на домашней недорогой машине на уровне вашей пачки SSD скорее всего в 10-100 раз дороже суммарно по стоимости его оперативки.
Я не про то, что 'Пачка SSD круто', а про то, что tmpfs медленный. У меня на столе ноутбук трёхлетней давности — он выдаёт 50к IOPS. Рамдиск выдаёт 300к. Не чувствуете дискомфорта?
Конечно, я согласен, что есть аппаратные решения с бОльшим быстродействием. Например, PCIe SSD и InfiniBand Flash/DRAM, но таки моя статья про недорогую домашнюю систему и чисто программное решение, простое. Да, значение IOPS меня несколько огорчило, ожидалось больше. Однако латентность радует, 0.29 микросекунд.
tmpfs медленный. У меня на столе ноутбук трёхлетней давности — он выдаёт 50к IOPS. Рамдиск выдаёт 300к.
Какой смысл сравнивать файловую систему с блочным устройством?
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ГБ оперативки, хотя на самом деле это не так.
Ну и вообще, мне способ не нравится, честно говоря. Squashfs можно собрать и с lzo, он будет летать и меньше места занимать, да и, к тому же, для squashfs в качестве rootfs уже куча скриптов написано, которые сами вам сделают tmpfs поверх squashfs через тот же overlayfs, который уже есть в ядре. Хочется безопасно эксперементировать с системой? Тогда лучше использовать снапшоты на любой ФС, их поддерживающей, например btrfs. Как эксперимент, конечно, не осуждается, но я не представляю, кому это может пригодится в реальной жизни.
Ну и не стоит забывать об очень, очень противной особенности tmpfs — он не показывается во free. Скажем, у автора 16ГБ оперативки, а tmpfs вдруг разросся до 8ГБ. У автора запущено дофига программ, он хочет запустить еще, везде написано, что оперативки достаточно, а на деле все свопится, или, если свопа нет, не запускается, или oomkiller вообще приходит. Везде написано, что свободно (именно свободно!) 8ГБ оперативки, хотя на самом деле это не так.
3.16.0-4
Побудило на эксперимент то, что сколько разных LiveCD с squashfs я не перепробовал, скорость запуска приложений не удовлетворила. Она была меньше, чем видно в скринкасте в конце статьи.
А эта особенность tmpfs разве не исправлена?
Побудило на эксперимент то, что сколько разных LiveCD с squashfs я не перепробовал, скорость запуска приложений не удовлетворила. Она была меньше, чем видно в скринкасте в конце статьи.
А эта особенность tmpfs разве не исправлена?
А эта особенность tmpfs разве не исправлена?Нет, насколько мне известно. Можно только смотреть реальную занятость памяти через /proc/meminfo.
Как тогда объяснить следующее? Я исполнил вот такой скрипт:
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 Гб меньше, а занятой — больше. Кэши сбрасывал.
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 Гб меньше, а занятой — больше. Кэши сбрасывал.
О, они починили, но у вас все еще нет. Вы должны смотреть не на строку 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 %
Присоединяйтесь:
en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM
По мне, так самый интересный это: tinycorelinux.net
Мое мнение, во всем этом нет смысла, выигрыш только при запуске, а не удобств полно.
Главный tmpfs — временная Ф.С., ваш КО.
Но для познавательных целей, конечно полезно.
en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM
По мне, так самый интересный это: tinycorelinux.net
Мое мнение, во всем этом нет смысла, выигрыш только при запуске, а не удобств полно.
Главный tmpfs — временная Ф.С., ваш КО.
Но для познавательных целей, конечно полезно.
А через overlayfs такое не сотворить?
Что-то я не понял, чем это лучше стандартной initramfs?
Берём нужную нам корневую файловую систему, заворачиваем её в cpio и даём грубу в параметре initrd. Всё.
Берём нужную нам корневую файловую систему, заворачиваем её в cpio и даём грубу в параметре initrd. Всё.
Я про это тоже думал, но мне тут не хватает знаний. Нужны ли какие-либо драйверы? Как это сделать в деталях? Буду благодарен, если распишете «для чайника». И чем будет в итоге это? Так и будет initramfs? Как она по производительности в сравнении с tmpfs? Рассчитана ли она на многогигабайтные размеры? Из линуксов «целиком в initrd» я видел только Damn Small Linux с initrd размером 50 Мб.
> Нужны ли какие-либо драйверы?
Ничего сверх того, что у вас и так есть.
> Как это сделать в деталях?
встать в корневой каталог корневой ФС, выполнить от рута
find -xdev -print0 | cpio -o --null -H newc | gzip > ...../rootfs.cpio.gz
Больше деталей: www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> Как она по производительности в сравнении с tmpfs?
По умолчанию она и есть tmpfs.
Ничего сверх того, что у вас и так есть.
> Как это сделать в деталях?
встать в корневой каталог корневой ФС, выполнить от рута
find -xdev -print0 | cpio -o --null -H newc | gzip > ...../rootfs.cpio.gz
Больше деталей: www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> Как она по производительности в сравнении с tmpfs?
По умолчанию она и есть tmpfs.
Хм, а где тесты 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
По 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
Диски — не SSD если что…
Тест fio по рандомной записи делал, а не приложил, потому что он принципиально не отличается. Вот скриншот randwrite: ccosplay.com/fio-randwrite.jpg
Тесты с dd я не соглашусь, что полностью бессмысленны. Задача последовательного чтения или записи большого файла часто встречается. В статьях о некорректности dd указывают на то, что он может не учитывать кэширование, но в данном случае кэширования нет — tmpfs не кэшируется вовсе. Собственно, копирование больших (несколько Гб) файлов в консоли или mc показывает те же результаты, что и dd, и информация о скорости этого копирования не бесполезна.
15.2 — это милли- или микросекунд? ms обычно обозначаются миллисекунды…
Тесты с dd я не соглашусь, что полностью бессмысленны. Задача последовательного чтения или записи большого файла часто встречается. В статьях о некорректности dd указывают на то, что он может не учитывать кэширование, но в данном случае кэширования нет — tmpfs не кэшируется вовсе. Собственно, копирование больших (несколько Гб) файлов в консоли или mc показывает те же результаты, что и dd, и информация о скорости этого копирования не бесполезна.
15.2 — это милли- или микросекунд? ms обычно обозначаются миллисекунды…
15.2 микросекунд (usec), ошибся, пардон…
Ну вот, а у меня 0.29 usec, что в 50 раз меньше. По идее, это должно влиять на отзывчивость системы в лучшую сторону…
Вообще в случае RAM-хранилищ нужно мерять по lat (у меня он порядка 17 us, у вас — 2 us), т.к. slat кхм… существенно выше clat :) тогда разница получается в 10 раз. Но с точки зрения пользователя с SATA диском (iops ~300 и lat 7000 us) — разница между tmpfs и ZFS несущественна в производительности, зато по набору опций… даже несравнимо.
По-моему, размер файла для теста у вас очень маленький. Эти 2ГБ полностью влазят в ARC и, естественно, отсюда такое большое значение IOPs.
Еще бы execute-in-place приделать — и будет совсем хорошо.
По-оему, обычного SSD вполне достаточно для обеспечения практически необходимого быстродействия.
Ну какая разница сколько грузится linux, если на нормальных серверах время старта самого сервера до операционной системы изменяется в минутах. А на ноутбуках, где с диском как раз беда, оперативной памяти много не бывает.
За статью всё равно спасибо — вдруг пригодится.
Ну какая разница сколько грузится linux, если на нормальных серверах время старта самого сервера до операционной системы изменяется в минутах. А на ноутбуках, где с диском как раз беда, оперативной памяти много не бывает.
За статью всё равно спасибо — вдруг пригодится.
Так не сколько грузится сам linux (раз в день и реже можно и подождать немного), а сколько грузится каждое приложение, работает оно с накопителем или с ОЗУ, с какой латентностью и т. д. Вот никто особо не воздал должное тому, что латентность памяти на несколько порядков меньше латентности любого SSD (микросекунды против миллисекунд)…
А почему на ноутбуках не бывает много оперативной памяти? Чаще всего есть два слота, можно поставить 2x8 Гб, я сам ставил…
А почему на ноутбуках не бывает много оперативной памяти? Чаще всего есть два слота, можно поставить 2x8 Гб, я сам ставил…
Так дорого получается ноут апгрейтить. Два слота на моделях выше среднего уровня. И ставить имеет смысл на ноут с хорошим процессором. В результате получается золотой ноутбук, который всё равно работает плохо по сравнению с десктопом.
А приложения грузятся всё равно достаточно быстро и с SSD. Тот же FireFox — несколько секунд, опять же не каждую минуту его грузят.
А приложения грузятся всё равно достаточно быстро и с SSD. Тот же FireFox — несколько секунд, опять же не каждую минуту его грузят.
Выходит несколько дорого, но что делать? Ноутбук используется как раз там, куда десктоп не возьмешь — в командировке, например, или вот в прошлом году пришлось мне лечь в больницу на месяц, а на работе было нежелательно делать паузу. Работа связана с экспертной оценкой большого числа веб-страниц, надо, чтобы браузер летал, чтобы ожидание открытия вкладок, подгрузки контента было минимальным, потому что секунды превратятся в итоге в часы. Пришлось утворить рам-загрузку на ноутбуке. Только в прошлом году я еще не знал, как это сделать в Linux, сделал для Windows — на десктопе-то давно уже так работало. Да нет, куча ноутбуков 16" за $350 была с двумя слотами под память, двуядерный Pentium 2.2 ГГц, помнится.
А какая у вас память используется?
Я прогнал у себя на рабочем сервере (там тоже tmpfs создан для некоторыз проектов):
Я прогнал у себя на рабочем сервере (там тоже tmpfs создан для некоторыз проектов):
Скрытый текст
На практике можно tmpfs применять и не столь радикально для увеличения нагрузочной способности, если ресурсы ограничены. Довелось как-то сооружать Web-сервер, с которого через канал 100 МБит/с иногда весьма активно скачиваются файлы объёмом примерно от 30 до 150 МБайт. В машинке, отведённой под этот сервер, был только один отсек для жёсткого диска (да и то 2,5 дюйма), и были сомнения насчёт работы сервера под нагрузкой, но зато можно было поставить довольно много ОЗУ, и появился резон читать файлы под скачивание не с диска, а из памяти. Накатил на этот диск Linux, в качестве Web-сервера поставил nginx, а Web-каталог ему сделал в tmpfs. При загрузке ОС скрипт автозапуска до старта nginx готовит файловую систему, в ней делает Web-каталог и копирует туда с жёсткого диска файлы под скачивание. Другой скрипт, запускаемый по cron, периодически сверяет содержимое эталонного каталога на жёстком диске с каталогом в tmpfs и обновляет файлы в Web-каталоге при обновлении таковых в эталоне. В итоге цели поднятия этого сервера были достигнуты; машинка держит нагрузку с приличным запасом; думаю, при необходимости можно будет скорость канала ещё в несколько раз увеличить.
Господа, простите, ночь, может я туплю… А что если так:
— берем любой линкус
— выдаляем tmpfs раздел на нужное количество гигов
— ставим виртуальную машину с любой желаемой ОС
— размещаем файлы виртуалки на tmpfs
— запускаем, работаем, обновляем ОС, ставим программки
— выключаем
— синкаем файлы с tmpfs на любой персистентный носитель
— profit?
Ну да, будет просадочка на виртуализацию, но на современном железе она минимальна. Зато плюсы какие. Не? Попробуйте кто-нибудь? :)
— берем любой линкус
— выдаляем tmpfs раздел на нужное количество гигов
— ставим виртуальную машину с любой желаемой ОС
— размещаем файлы виртуалки на tmpfs
— запускаем, работаем, обновляем ОС, ставим программки
— выключаем
— синкаем файлы с tmpfs на любой персистентный носитель
— profit?
Ну да, будет просадочка на виртуализацию, но на современном железе она минимальна. Зато плюсы какие. Не? Попробуйте кто-нибудь? :)
А ГИМП даже на рамдиске грузится дольше всех…
Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.
Если не сложно, опишите более подробно — как это у Вас реализовано.
Во-первых, статья решительно ни о чем. Человек открыл для себя tmpfs. Поздравляю, он существует уже лет 27 вообще и около 14 лет в линуксе.
Во-вторых, для Вашего сценария достаточно весь образ системы засунуть в initramfs: начиная с ядер 2.6, если в ядре есть tmpfs, то rootfs — это tmpfs (если не указано иное в параметрах ядра) — см. www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt Ради чего делать вторую tmpfs поверх — непонятно.
Во-вторых, для Вашего сценария достаточно весь образ системы засунуть в initramfs: начиная с ядер 2.6, если в ядре есть tmpfs, то rootfs — это tmpfs (если не указано иное в параметрах ядра) — см. www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt Ради чего делать вторую tmpfs поверх — непонятно.
Я обещаю поставить опыт с initramfs. Если всё так, то это здорово упрощает дело и статья действительно становится праздной. Но все же у меня есть сомнения, что все пройдет гладко. И нужна ли правка fstab в этом случае?
Поставил опыт. Увы, вот так просто «в лоб» не работает. Initramfs читается и распаковывается, но затем Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Видимо, нужны некторые ключевые детали, о которых вы не упомянули…
Видимо, нужны некторые ключевые детали, о которых вы не упомянули…
В systemd прилетел коммит, который позволяет делать точно то же, что описывает автор, стандартными средствами.
www.phoronix.com/scan.php?page=news_item&px=Systemd-Stateless-Root
www.phoronix.com/scan.php?page=news_item&px=Systemd-Stateless-Root
Я вижу только fstab генератор для root on tmpfs, а остальное как? Всё в initramfs.cpio.gz?
Да.
Kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Пробовал и со своим fstab, и с пустым — то же самое. Ядро пытается монтировать root fs на блочное устройство???
Пробовал и со своим fstab, и с пустым — то же самое. Ядро пытается монтировать root fs на блочное устройство???
ИМХО это переводится как «Невозможно монтировать rootfs, расположенную на блочном устройстве».
Сообщение, как правило, означает, что указанного блочного устройства просто-напросто нет. У меня такое наблюдалось, когда ОС находилась на usb флешке, а usb драйвера в initrd включены не были. В вашем случае не знаю в чём дело. Предположу, что в скрипте init пропущен этап заполнения /dev. Измените скрипт init, вставив вызов "/bin/bash -i" перед попыткой скрипта что-то смонтировать. Потом как попадаете в этот bash при старте, уже в интерактивном режиме пытайтесь что-то смонтировать, выяснить что не так с системой, и т.д.
Сообщение, как правило, означает, что указанного блочного устройства просто-напросто нет. У меня такое наблюдалось, когда ОС находилась на usb флешке, а usb драйвера в initrd включены не были. В вашем случае не знаю в чём дело. Предположу, что в скрипте init пропущен этап заполнения /dev. Измените скрипт init, вставив вызов "/bin/bash -i" перед попыткой скрипта что-то смонтировать. Потом как попадаете в этот bash при старте, уже в интерактивном режиме пытайтесь что-то смонтировать, выяснить что не так с системой, и т.д.
Все это напоминает школьное детство. Возможно, было бы больше толку от статьи, в которой было бы рассмотрено:
Мне непонятно, чего хотел добиться автор, и почему его решение хорошее. Запускать LibreOffice за 0.5 c вместо 1 с? Так никто обычно не запускает тяжелые программы, чтобы сразу из них выйти. Ну и полноте жаловаться, на SSD все и так запускается достаточно быстро.
- ситуации, когда нам нужна максимальная стабильность и отсутствие необходимости вмешательства в случае выключений/перезагрузок
- роутеры
- платежные терминалы
- способы этого достичь
- монтировать надежную fs в read-only
- squashfs
- tmpfs
- другое
- споосбы автоматического обновления полученной системы (вручную перезакатывать архив каждый раз мучительно и легко забыть это сделать или ошибиться)
Мне непонятно, чего хотел добиться автор, и почему его решение хорошее. Запускать LibreOffice за 0.5 c вместо 1 с? Так никто обычно не запускает тяжелые программы, чтобы сразу из них выйти. Ну и полноте жаловаться, на SSD все и так запускается достаточно быстро.
После запуска программы разве она больше не производит дисковых операций? Еще как производит. SSD и кэширование придумали именно для этого. Однако можно и быстрее, что я и продемонстрировал. Я реально в такой системе работаю (как в Linux, так и в Windows), и ни за какие коврижки не соглашусь обратно на HDD и даже на SSD. Потому что медленно. Ну и на одной из работ критично, смогу я открыть и исследовать, например, 1000 веб-страниц за 8 часов или же за 5 часов, потому что это нужно делать ежедневно, и когда узкое место — моя собственная производительность, то это одно, а когда подтормаживает машина, то это очень печалит и вынимает з/п из кошелька и уменьшает время на отдых.
Я не знаю точно, как устроен firefox, но не уверен, что файловая система на tmpfs ускоряет открывание 1000 вкладок. Первый запуск, возможно. Но открытые страницы firefox хранит не на диске, а в памяти, которую вы у него забрали. В любом случае, возможно, достаточно было бы перенсти профиль firefox на tmpfs.
У вас личная неприязнь к автору? Это уже второй коммент с общей мыслью «не знаю зачем эта ваша initrd-only ОС, у кого-то избыток свободного времени, у меня на SSD всё работает с той же скоростью.» Высокомерие — плохая черта. Статья нужна потому, что она демонстрирует, что можно поместить ОС за пару простых действий целиком в память. Это как минимум стимулирует тех читателей, кто раньше не знал / не задумывался о такой возможности, глубже познакомиться с устройством init в дебиане, с initramfs/unionfs, задуматься о плюсах переноса какого-нибудь содержимого с харда на виртуальный диск. Люди разные, машины и задачи у них разные, у кого-то SSD, у кого-то HDD, у кого-то бездисковый тонкий клиент. В комментах выше пару кейсов привели, когда initrd нужен.
Это не высокомерие. Удивлен, что столько внимание привлекла статья, которая не рассматривает ни альтернативные решения, нет никаких сравнений производительности (я вот не уверен, что производительность в целом выше, так как производительность — это не только скорость запуска firefox), надежности, совершенно не продуманы вопросы обновления.
Автор описал только два преимущества:
— быстро запускаются приложения (что, в общем, не так уж важно при реальной работе)
— можно выключать/перезагружать компьютер в любой момент (что, в общем, тоже не особо необходимо в обычной работе, так как ничто не мешает выполнять полноценный shutdown)
Автор описал только два преимущества:
— быстро запускаются приложения (что, в общем, не так уж важно при реальной работе)
— можно выключать/перезагружать компьютер в любой момент (что, в общем, тоже не особо необходимо в обычной работе, так как ничто не мешает выполнять полноценный shutdown)
Поддержу комментатора immaculate.
Как-то пару лет назад, когда приобрёл 16 гигов оперативки, так же стало интересно, как это можно систему запихнуть в оперативку и ВСЁ БУДЕТ ЛЕТАТЬ!!!!1
Долго ковырялся, копал, перепробовал кучу вариантов. Поработал в таком режиме пару недель, вся эта канитель взбесила — купил SSD. Поставил, оттюнил, разницы с рам-диском на глаз не заметил. Зато, ПОСТАВИЛ — РАБОТАЕТ.
Потом стал замечать, что занято примерно 8 гигов максимум, остальное забито кешем. Выделил 4 гига под рам-диск для временных нужд: что-то скомпилить по-быстрому, какой-нить здоровый файл обработать. Всё, больше не нужно ни для чего.
Это я про винду.
В линуксе же есть, например, anything-sync-daemon, который любую папку пихает в рам и как положено там всё rsync'ает. Не нужно изобретать велосипеды, всё до нас уже изобрели. Это всё интересно исключительно для собственного развития: понять как оно там работает, поковырять, разобраться, допереть, что уже давно кем-то реализовано лучше, и воспользоваться готовым решением.
Как-то пару лет назад, когда приобрёл 16 гигов оперативки, так же стало интересно, как это можно систему запихнуть в оперативку и ВСЁ БУДЕТ ЛЕТАТЬ!!!!1
Долго ковырялся, копал, перепробовал кучу вариантов. Поработал в таком режиме пару недель, вся эта канитель взбесила — купил SSD. Поставил, оттюнил, разницы с рам-диском на глаз не заметил. Зато, ПОСТАВИЛ — РАБОТАЕТ.
Потом стал замечать, что занято примерно 8 гигов максимум, остальное забито кешем. Выделил 4 гига под рам-диск для временных нужд: что-то скомпилить по-быстрому, какой-нить здоровый файл обработать. Всё, больше не нужно ни для чего.
Это я про винду.
В линуксе же есть, например, anything-sync-daemon, который любую папку пихает в рам и как положено там всё rsync'ает. Не нужно изобретать велосипеды, всё до нас уже изобрели. Это всё интересно исключительно для собственного развития: понять как оно там работает, поковырять, разобраться, допереть, что уже давно кем-то реализовано лучше, и воспользоваться готовым решением.
Теперь представим ситуацию: у вас над ухом стоит начальник, который с делегацией, и вам нужно очень быстро показать ему что-то. Вы запускаете это что-то и… именно в этот момент в кэше этого нет, в рам были отправлены другие папки, произошло еще что-то, и т. д. и т. п. Начальник ждет ровно 3 секунды и идет дальше с делегацией, вы не получили ничего. Я утрирую, но общий смысл в том, что если в системе есть медленные устройства, то это обязательно так или иначе будет сказываться. Я бы хотел, чтобы об этом вообще думали, искали новые решения, а не довольствовались тем, что уже изобретено. Да, данный способ имеет недостатки. Придумайте лучший, еще более быстрый, без недостатков, может быть, вообще аппаратный, чтобы при помощи паяльника каждый мог сделать у себя дома.
В большинстве систем даже с SSD самым медленным устройством оказывается процессор, т. к. ввод-вывод начинает упираться именно в него, в постоянную смену контекста потоков, промахи кеша, миллионы неоптимальных сисколов без scatter-gather и т. д. Все эти тесты слишком синтетичны и не отражают реалий современного быдлокодерства. Тот же Экслипс хоть на марсоходе запускай, меньше, чем за 4-5 секунд он не стартует без тонкой настройки.
А мне то зачем придумывать? Меня вполне устраивает мой ссдшник с его производительностью и демоном синхронизации с рам-диском.
Я абсолютно не против поиска подобных костылей, сам раньше позволял себе копаться в чём-то, досконально разбираться, а сейчас пришло понимание, что лучше потратить в 10 раз меньше времени, воспользоваться готовым решением, и потерять максимум 20% производительности.
А мне то зачем придумывать? Меня вполне устраивает мой ссдшник с его производительностью и демоном синхронизации с рам-диском.
Я абсолютно не против поиска подобных костылей, сам раньше позволял себе копаться в чём-то, досконально разбираться, а сейчас пришло понимание, что лучше потратить в 10 раз меньше времени, воспользоваться готовым решением, и потерять максимум 20% производительности.
Как человек, в 2015 году пишущий оконные приложения для Win 8.1 x86 на ассемблере, вполне соглашусь с первым абзацем.
О! С этого и надо было начинать статью. Я бы не стал тратить время на комментирование. :)
А узнав, что Алан Тьюринг был геем, вы бы стали читать его труды по логике? Вы считаете, что его ориентация ухудшила качество его работ? А шизофрения Джона Нэша — ухудшила качество его математических работ? Или, может быть, язык ассемблера — это что-то, что хуже педерастии и шизофрении?
Вы очень лично все восприняли, мне жаль. А я не осуждаю, но и не одобряю. Я просто оптимизирую жизнь, программы, системы по другому принципу. С моей точки зрения, считать такты на ассемблере бессмысленно, потому что пока я буду их считать, поезд уже уйдет, и программа будет не нужна ни мне, ни кому-либо другому. Ложка дорога к обеду.
Тратить жизненное время на перемещение всего в tmpfs для меня из той же оперы. Я может быть получу ускорение, если повторю ваш опыт, даже предусмотрю обновления и какую-то персистентность программ и данных. Но мне это не нужно, так как без бенчмарков мне кажется, что исчезнувшая память отъест, например, кэш у postgresql и других программ, и на самом деле моя работа станет медленнее и неудобнее… И все это решение какое-то неизящное, непродуманное, непроверенное.
Как у мотоцикла люди отпиливают глушитель, потому что громко (в междурядье замечают), круто, пару лошадиных сил прибавляет. А потом у них поршни прогорают на самом деле.
В общем, нет у меня ни высокомерия, ни осуждения. Какая-то эмоция впрочем есть, потому что все же в нескольких комментариях отметился.
Тратить жизненное время на перемещение всего в tmpfs для меня из той же оперы. Я может быть получу ускорение, если повторю ваш опыт, даже предусмотрю обновления и какую-то персистентность программ и данных. Но мне это не нужно, так как без бенчмарков мне кажется, что исчезнувшая память отъест, например, кэш у postgresql и других программ, и на самом деле моя работа станет медленнее и неудобнее… И все это решение какое-то неизящное, непродуманное, непроверенное.
Как у мотоцикла люди отпиливают глушитель, потому что громко (в междурядье замечают), круто, пару лошадиных сил прибавляет. А потом у них поршни прогорают на самом деле.
В общем, нет у меня ни высокомерия, ни осуждения. Какая-то эмоция впрочем есть, потому что все же в нескольких комментариях отметился.
Вы осуждаете, и не просто, а именно «не читал, но осуждаю» (с), потому что не изучаете и не тестируете, а «без бенчмарков мне кажется». И здесь не пара лошадиных сил, а по ряду параметров разница на порядок с SSD и на несколько порядков с HDD.
Написание программ на ассемблере не занимает больше времени, чем на любом другом языке, и не является более сложным и трудоемким, чем на любом другом языке.
Написание программ на ассемблере не занимает больше времени, чем на любом другом языке, и не является более сложным и трудоемким, чем на любом другом языке.
Таки Алан Тьюринг был педофилом, разве нет?
Ну если бы Алан Тьюринг высказал своё мнение о том, что мужчины во всех отношениях красивее и привлекательнее женщин, я бы не стал прислушиваться к его мнению.
Мне непонятно, чего хотел добиться автор, и почему его решение хорошее. Запускать LibreOffice за 0.5 c вместо 1 с? Так никто обычно не запускает тяжелые программы, чтобы сразу из них выйти. Ну и полноте жаловаться, на SSD все и так запускается достаточно быстро.
Рискну предположить, что в большинстве случаев тяжёлые программы висят постоянно в памяти именно из-за того, что они тяжёлые, и операция запуска отнимает слишком много времени.
Имхо, для полноценного решения надо полностью менять концепцию «быстрая память/медленная память» и разрабатывать какую-нибудь TurboRamOS.
Эффектно…
Но лично для меня, без авто обновления архива, не применимо.
P.S. А в гибернацию такая система ляжет? ;)
Но лично для меня, без авто обновления архива, не применимо.
P.S. А в гибернацию такая система ляжет? ;)
Гибернацию не проверял, так как все системники работают 24/7. Скорее всего, да, при наличии достаточно RAM.
RAM — это Suspend, а гибернация на диск делается. Впрочем не вижу никакой причины не работать гибернации, только своп для этого нужен большой.
STR — Suspend to RAM, STD — Suspend to Disk или они нынче больше не работают?
Не совсем понял, о чем Вы. Я же о том, что Гибернацией (как правило) называют Suspend to Disk. Т.е. сбрасывание всей памяти на диск (в Линуксе это, как правило своп) и отключение питания процессора и памяти.
А Suspend to RAM часто (так скажем раньше) просто называют Suspend, т.е просто приостановка всех приложений и перевод процессора в спящий режим.
Если я ничего не напутал, то исходя из этого большое количество RAM совершенно не нужно для гибернации, а даже наоборот — несколько вредно.
А Suspend to RAM часто (так скажем раньше) просто называют Suspend, т.е просто приостановка всех приложений и перевод процессора в спящий режим.
Если я ничего не напутал, то исходя из этого большое количество RAM совершенно не нужно для гибернации, а даже наоборот — несколько вредно.
А что будет при неожиданной потере питания?
Проделал всё это на своем amd64 дебиане. Работает.
Не скажу чтобы прям вот мгновенно все открывается. Программы потяжелели, их уже ничто не вылечит. Но некоторые диско-затратные вещи стали заметно быстрее.
Система весит 6 гигабайт (установлено 8). Попробую поиграться с монтированием, может быть, не все файлы нужны. Можно после запуска стереть ненужное. Оно же все равно вернется после ребута.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Файловая система Linux полностью на tmpfs — скорость без компромиссов