Персистентная оперативка — очень простая и очень непростая вещь.
В целом, всё просто: представьте себе, что содержимое оперативной памяти не пропадает. Никогда. Например, при выключении компьютера. Или, например, при… исчезновении компьютера. «И души умерших программ носятся над водою».
Ну, действительно — неважно: если мы смогли спасти состояние компьютера перед его отключением, то можно восстановить это состояние в другом. Таком же. Вообще таком же? Прямо до микросхемы? А если в нём видеокарта другая — уже нельзя?
Можно, потому что мы говорим не о том, чтобы заперсистить, сохранить всё состояние компьютера, а только его оперативную память. Но тогда в этом нет пользы, скажет внимательный читатель — уже хотя бы регистры надо бы сохранить? Иначе восстановление только памяти не позволит программе работать как если бы ничего не происходило.
А задача — именно такова. Обеспечить программе среду, в которой остановка ОС и остановка компьютера для программы выглядели исключительно как нажатие на кнопку «пауза» при просмотре фильма. Во время паузы «под программой» можно даже компьютер поменять, но надо как-то обеспечить ситуацию, в которой продолжение работы для программы будет совершенно прозрачным.
Это недостижимо, если требование доводить до абсолюта. Состояние хардвера сохранить и полностью восстановить нельзя. Но и не надо. Программе не нужна видеокарта, ей нужен тот же API и сохранённая картинка на экране, а это — можно.
Что вырисовывается: сохранить состояние только оперативки — мало, а всего компьютера — нереально.
Инженерная смекалка говорит нам, что нужно специфицировать для программы некоторую среду, которой во-первых, достаточно для самой программы, а во-вторых, в рамках такой среды должно быть возможно выполнить сохранение консистентного состояния программы и всего, что она «видит».
Легко видеть, что такой средой является спецификация операционной системы. Ну — не любой. Хорошей операционной системы. Системы, которая достаточно качественно скрывает от приложения детали аппаратуры (и вообще бренности окружающего мира).
Следовательно, вообще-то, говорит надо не о персистентной (виртуальной) памяти, а о персистентной среде исполнения = персистентной ОС. Собственно, это и есть проект ОС Фантом, но сегодня я принципиально ограничусь, всё же, вопросом только оперативки, иначе статью не получится дописать к утру.
Итак, мы понимаем, что персистентная память окружена другими персистентными сервисами, и пока откладываем их в сторону.
Ясна так же и цель войны. Ясна? Нет?
Цель — упростить жизнь программиста до неприличия. Избавить его от работы по сериализации стейта программы. И от ограничений, которые он на себя накладывает, проектируя внутреннее представление данных в программе, держа в уме, что всё это рано или поздно придётся втискивать в прокрустово ложе потока байт, которым является файл.
Ну — вот простой пример: habrahabr.ru/company/2gis/blog/198564
Вместо того, чтобы воевать с ФС, можно просто забыть про неё как про страшный сон. Очевидно, что это вызывает массу вопросов про обмен данными, но, вообще-то, признаемся себе, что обмен тоже давно уже происходит не через файлы, а через REST/SOAP/whatever, и тоже не в формате сериализации дерева в байт-стрим, а в виде запросов объектов или «ветвей» дерева объектов. Что, очевидно, соответствует вовсе не «файловой» семантике, а тому представлению данных, которое сподручно для самой программы.
Хорошо, цель ясна. Теперь средство. Как же записать память на диск?
Ну, write( fd, (void *)0, get_mem_size() ), верно?
Конечно, нет. По многим причинам. И потому, что в памяти могут быть «дырки» — не отображённые никуда области, доступ к которым запрещён. И потому, что совсем незачем записывать то, что не менялось. Да тот же код — зачем? Да и, главное, потому, что это дико дорого.
И уж совсем важно, что программу во время записи придётся остановить. А вот это уже никуда не гоже вообще.
Дело тут вот в чём. Если мы хотим (а мы хотим), чтобы прикладная программа нам доверяла и правда не пыталась для спокойствия всё-таки записаться в файл (а это убивает всю идею вообще), надо ей гарантировать, нет ГАРАНТИРОВАТЬ, что мы её обязательно сохраним. Может быть, не совсем в последнем состоянии (это не так важно — она повторит часть вычислений), но в целостном и не позавчерашнем.
То есть — состояние программы (чуть позже мы выясним, что это состояние всех программ вообще) нельзя сохранять по старинке — перед выключением компьютера или по ctrl-s, это надо делать постоянно. Или, как минимум, достаточно регулярно. И нередко.
Вряд ли пользователь, а тем более — управляемый компьютером технологический процесс будет доволен сообщением «сохраняю оперативную память» на минутку-другую.
Надо научиться сохранять состояние в фоновом режиме, потихоньку, прямо «под» работающей программой.
Но тогда оно будет неконсистентным! Мы сохранили левую половину состояния программы, а когда начали сохранять правую, программа уже наработала что-то новенькое — половины «не срастутся» при рестарте. Программа добавит в левую половину объект, поставит на него ссылку из правой половины, а в «фотографии» состояния окажется, что ссылка есть, а объекта — нет.
Сохранённое состояние должно быть строго, абсолютно, консистентным. Но делать его надо последовательно.
Можно?
Можно.
Есть множество эвристик, которые позволяют удешевить и облегчить такой процесс, но в основе лежит обычный COW, copy on write.
Если утрировать до предела, то фотографирование состояния сводится к мгновенному переключению всей памяти в read only — это единственная (и крайне недорогая) операция, которую нужно сделать атомарно. (Заранее оговоримся, что перед ней нужно загнать программы в состояние, которое полностью представлено в памяти. А не в регистрах процессора. Что тоже несложно и недорого).
Это, собственно, «точка фотографирования».
Дальше процесс обретает известную медитативность и может быть выполнен без вырывания волос из естественных впадин организма, спокойно и с расстановкой. Страницы памяти можно спокойно записывать на диск одна за одной. А что ж программа? Она, конечно, не будет ждать и попробует в какую-то страницу памяти таки записать что-то. Такая страница разделяется на пару — старая, неизменная копия встаёт в очередь на запись на диск (поближе к началу), а новая используется и модифицируется программой. Когда запись на диск закончится, старые копии будут уничтожены.
Как я уже говорил, это только черновик. Есть масса деталей. (Желающие взорвать мозг могут заглянуть в код прямо сейчас.)
Очевидная оптимизация — записывать только diff-ы. С прошлого раза поменялось очень не всё.
Столь же очевидная, но более спорная и требующая эвристик оптимизация — что-то записать до точки фотографирования (и переключить в r/o), в надежде, что оно не изменится. Тогда можно будет просто использовать готовый записанный блок на диске, не повторяя дисковой операции для этой страницы памяти.
Понятно так же, что рабочее множество программы (точнее, его не read only часть) потенциально удвоится за время записи снапшота: если нам не повезёт, то пока мы будем записывать состояние, программа «перетрогает», перезапишет все свои странички и всем им придётся выделить вторую физическую страницу оперативной памяти. То есть при невезении затраты оперативки удвоятся во время снапшота. Реально ситуация всегда мягче, но «спрос» на оперативку во время снапшота неизбежно возрастает. Чтобы его удовлетворить, не останавливая программы по причине нехватки оперативки, хорошо бы перед снапшотом немного подготовиться, позаписывать на диск странички, которые изменились — тогда у них можно будет «отобрать» физическую страницу памяти, если она срочно потребуется в другом месте. Опять же, внимательный читатель увидит, что выше уже сказано про позаписывать на диск превентивно, но в других целях.
Превентивная запись улучшает и другой показатель. Латентность снапшота — время между «фотографированием» и окончанием записи фотографии на диск.
Отмечу, что всё это на сегодня вполне реализовано и работает в ядре ОС.
В этом месте поставим точку с запятой. Через некоторое время я постараюсь написать статью, которая связывает предыдущую тему — примитивы синхронизации — и эту. То есть написать о проблемах реализации примитивов синхронизации в персистентной памяти.
И это уже будет статья о том, что до сих пор как следует не сделано. То есть, в существенной степени она будет состоять из вопросов.
Комментарии (63)
OldFisher
16.03.2016 17:03А можно в общих чертах прокомментировать, как эта концепция дружит с энергонезависимой оперативной памятью? А то тут на днях рассказывали, что RRAM пойдёт на коммерциализацию и вообще обещают подвижки в этой области.
dzavalishin
16.03.2016 17:12+4Конечно. Появление RRAM позволит снизить латентность снапшота (не уверен, что до нуля, но сильно). Но общая машинерия никуда не денется пока объём RAM меньше объёма диска. А вот потом… это совсем интересно. :)
Но, опять, же, тут важно иметь концепцию персистентной системы, а сам механизм обеспечения персистентности вторичен. Если он появится в бесплатном виде — отлично.
Я планирую написать ещё несколько статей про вопросы сопряжения персистентной среды с реальным миром — вопросы разрыва линии времени.OldFisher
16.03.2016 17:22Так ведь, насколько я понимаю, самое вкусное в перспективах такой памяти как раз в том, что исчезает разделение на оперативное и постоянное хранение, исчезает само понятие "диск" и производные, вроде "загрузки". Вот когда понадобятся во всю силу ОС, построенные на этих принципах.
dzavalishin
16.03.2016 17:29Конечно.
OldFisher
16.03.2016 20:04+2Так вот и хотелось бы увидеть комментарии от вас, как от работающего в этом направлении человека, что будет в таких условиях. Каково это — когда сразу все программы и данные всегда "загружены" в память, когда нет и не нужно никакого "сохранения"? Как изменятся принципы написания программ, взаимодействия, хранения данных? Что станет с пользовательским интерфейсом? Какие ещё интересные изменения привнесёт это нововведение?
dzavalishin
16.03.2016 21:26+1Предмет отдельной серии статей. Где бы достать ещё часов 10-12 в сутки. :)
Наверное, со временем напишу.
CodeRush
16.03.2016 17:33Поддержку NVDIMM уже добавили в UEFI 2.5, доступные реализации которого на подходе вместе со следующим поколением десктопных процессоров Intel с микроархитектурой Kaby Lake. По поводу железа — инженерные образцы уже циркулируют, но до открытой продажи еще примерно с год. Что со стороны ОС — пока не знаю, железо подходящее его не попадало в руки.
blind_oracle
16.03.2016 18:18Насколько я помню поддержку подобной функциональности (суспенд отдельных процессов на диск и последующее оживление) анонсировали для Linux. Не знаю, довели до продакшена или нет.
dzavalishin
16.03.2016 21:26CRIU?
blind_oracle
16.03.2016 21:45Ага, точно, оно. Даже развивается активно, не ожидал. И на ванильном ядре работает.
dzavalishin
16.03.2016 23:01+1Это же люди из Parallels делают. Недавно общался с ними, то ли на OS Day, то ли на семинаре Петренко в МГУ, не помню. Отличная работа, очень полезная в прикладном смысла. Но там тоже нельзя сделать снапшот без остановки процесса.
BVadim
16.03.2016 22:04Вот крутое демо, сервер Quake в контейнере переносят между датацентрами с сохранением состояния и сетевого подключения. https://www.youtube.com/watch?v=MHJmNZSRve0&feature=youtu.be&t=1328
blind_oracle
16.03.2016 22:16Ну, это не совсем то же самое. Это скорее аналог vMotion и подобных ей технологий, которые уже достаточно много лет присутствуют в виртуализации.
BVadim
17.03.2016 01:19На видео состояние сохраняется и восстанавливается как раз через CRIU. Они используют runc checkpoint, который в свою очередь работает через CRIU.
nerudo
16.03.2016 18:37У меня такое ощущение, что OS/400, к примеру, так и работает используя стандартную "оперативку" в качестве кэша.
BalinTomsk
16.03.2016 18:48https://geektimes.ru/post/251686/
Кроме того, одной из фишек ОС была способность откатывать, при сбое и ре-старте, ОС и задачи с последнего сохраненного места.
Примерно как сейчас делает это ноутбук – закрыл – открыл крышку – все задачи бегут, как будто не останавливались. Для этого в С добавилась возможность для каждой задачи сохранять промежуточные данные, с которых она могла ре-стартовать.dzavalishin
16.03.2016 21:29:) Интересно, спасибо.
Но делать это на уровне задачи можно только в режиме старт-стоп — прозрачное сохранение без останова кода так сделать нельзя.
neit_kas
17.03.2016 00:03Но, стоит отметить, перезагружать время от времени всё равно приходится. Хотя бы из-за утечек памяти.
gurinderu
16.03.2016 19:45dzavalishin Как часто в вашей ОС приходится менять HDD?
23derevo
16.03.2016 19:50+1а вы вообще уверены, что Фантом увеличивает нагрузку на HDD/SDD и сокращает срок его службы?
gurinderu
16.03.2016 20:48Нет, Алексей. Я в этом не уверен, поэтому и спрашиваю.
Но в любом случае, следуя логике, операции записи на HDD/SSD должно стать больше. Отсюда и моё предположение.
dzavalishin
16.03.2016 21:36+1Не знаю пока. Хорошо бы выйти на какое-то серийное применение, чтобы начать собирать такую статистику. Этот вопрос реально сложнее, чем может показаться. Например, объём ввода-вывода зависит от реализации аллокатора памяти. Тупой аллокатор при выделении памяти идёт "по кругу" и "трогает" всю память даже если программе в каждый момент времени хватает килобайта. Соответственно, система снапшотов будет считать её изменившейся и записывать, хотя ничего актуального там нет. Есть два выхода: дорабатывать аллокатор с тем, чтобы он работал более локально, и/или дорабатывать систему снапшотов, чтобы она не пыталась записывать память, которая была выделена и освобождена полностью между снапшотами. Эти доработки могут снизить нагрузку на диск на несколько порядков.
gurinderu
17.03.2016 11:52А если не секрет, как система снепшотов определяет изменения и как часто она дампится на диск?
dzavalishin
18.03.2016 13:02Какой уж секрет — я ссылку на исходники дал. :)
Изменения определяет процессор по пейдж фолту на запись: после снапшота все страницы, естественно, в read only и попытка записи вызывает эксепшн процессора, в котором мы и маркируем страницу как изменившуюся. Это банально.
Как часто — это вопрос настройки. Сейчас стоит пауза в 100 секунд, но сам снепшот длинный — в системе стоят проверки на целостность. Итоговый цикл — минут 10, наверное. В боевой версии можно сделать цикл в единицы секунд. При условии того, что объём модификации страниц невелик.gurinderu
18.03.2016 13:43Понятно. Исходники конечно хорошо, но там кода мама не горюй)
А почему не сделает «реактивное» изменение? Боитесь упереться в пропускную способность жесткого носителя?
Если стоит пауза в 100, то есть очень большой шанс получить не консистентность данных на выходе.
vagran
16.03.2016 20:32+1А не было бы на порядки проще и эффективнее реализовать подобную концепцию не в виде ОС, а в виде user-space runtime environment в существующей ОС, например, под Линуксом на основе memory mapped файлов? Ну может ещё какой модуль ядра забахать.
dzavalishin
16.03.2016 21:40х его з. может и да.
есть и третий вариант — сесть под микроядро L4
но не факт, что было бы проще. сам код ядра не так уж и велик.
изначально я взял всю ядерную инфраструктуру из oskit, что было условно бесплатно. потом переписал всё это с чистого листа, чтобы уйти от чужого кода, что происходило плавно и тоже напряга не принесло. А вот тот исходник, что по ссылке, писать пришлось бы и так, и так. И вряд ли было бы проще.
Другое дело, что не было бы проблем с драйверами и пр.vagran
16.03.2016 22:07Ну я именно за вариант с реализацией в user space. И именно по причине того, что будет готовая абстракция от железа с огромным пластом драйверов. Отставание по количеству и качеству драйверов, написанных за десятки лет для Линукса в своей ОС нагнать нереально. Да и не нужно это, ведь цель не в этом, а в создании ортогонально персистентной среды. У вас же получается, что вместо полной концентрации на реализции этой концепции приходится распыляться на свою реализацию TCP/IP, USB и прочего бесконечно огромного и глубокого болота, с заведомо провальным результатом (извините, но взять любой из необходимых компонентов — тот же TCP/IP — чтобы его реализовать качественно, по всем спецификациям, производительно, без уязвимостей, так чтобы этой реализации доверяли и без опасений реально использовали в боевых проектах, необходимо огромное количество ресурсов на тестирование и разработку).
dzavalishin
16.03.2016 23:10Есть простой ответ на этот вопрос — садиться на гипервизор. Но — да, частичный. Реализацию стека TCP он не заменяет.
Вариант с L4 позволяет рядом поднять Линукс и опереться на его TCP, но непонятно, что будет с производительностью.
Есть и обратная сторона медали — для доверенных применений верификация кода Фантома несравнимо проще верификации ядра Линукса. Не то, что бы это для меня принципиально, но — тоже фактор.
Есть и третья сторона медали. Как только у меня появится Линукс хотя бы на горизонте, стройные ряды #удаков начнут орать, что никакой ОС нету, и всё это тупо перелицованный Линукс. Вон уже рассказывают по разным углам, что я всё украл у Эроса, про который я узнал-то когда Фантом уже работал.
В общем, в данный момент моя задача — выйти на работоспособность прикладной среды. Нельзя сказать, чтобы проблем по собственно ядру было мало, но, в целом, процесс выглядит сходящимся.
(Сказал он, и посмотрел на 14 new issues и 15 closed issues.:)
symbix
16.03.2016 20:41+1Это очень напоминает live migration виртуальных машин. :-) А кстати судя по описанию в Фантоме же по сути виртуальная машина и есть, с каким-нибудь JIT. Тогда, если там Generational GC, напрашивается совмещение персистера и вычисления диффов с собственно фазами GC, даже по названиям похоже.
Goodkat
16.03.2016 21:06+3В идеальном мире это и заработает, может быть. Когда напишут идеальные программы без утечек памяти.
А в реальном мире я вынужден два-три раза в день прибивать процесс Firefox, так как он начинает глючить и тормозить, отказывается загружать js и css, когда потребление памяти подбирается к 3 ГБ.dzavalishin
16.03.2016 21:46Вы знаете, прогресс в IT постоянно лишает программистов какой-либо былОй халявы. Как было написано в какой-то книжке (Хакерз, чтоли?) — до "не пользуйся при программировании goto" было "не пользуйся при программировании паяльником". Когда-то надо научаться и с ресурсами работать. Перестать на Си писать, наконец. Ну ведь как-то удаётся делать Явские энтерпрайз-системы, которые работают месяцами под дикой нагрузкой и не текут. GC помогает, ну и определённое качество проектирования.
neit_kas
17.03.2016 00:16Опять таки, всё это очень здорово для серверов и каких-либо промышленных реализаций, где софт пишут на века. Но на обычном домашнем ПК, где софт частенько написан неким, кто вчера закончил универ и возомнил себя мега программистом, проблема с утечкой памяти приобретает нешуточный размах.
dzavalishin
18.03.2016 13:05Да, в общем, тоже не обязательно. Миллионы студентов пишут веб-странички на PHP — не течёт же. Почему? Потому что сборка мусора и потому, что отдельный запрос = отдельный контекст, который полностью убивается по окончании выполнения запроса. Что бы там внутри ни утекло — запрос заканчивается вместе со всеми вложенными данными.
norguhtar
18.03.2016 13:32Миллионы студентов пишут веб-странички на PHP — не течёт же. Почему?
Потому что CGI. У php до сих пор скрипт как закончился, так умер. Скорость увеличивается за счет кеширования результатов интерпретации.dzavalishin
22.03.2016 00:53"и потому, что отдельный запрос = отдельный контекст, который полностью убивается по окончании выполнения запроса."
neit_kas
18.03.2016 18:59При этом тот же Firefox течёт довольно не слабо. Я люблю, когда открыто много вкладок, точнее они то открываются, то закрываются. В общем, при такой кутерме к концу дня до 1,5 ГиБ набегает. Это я к тому, что всех разом и резко не научишь писать без утечек, из чего вытекает логичный вывод: нужно это учитывать.
Кстати, ещё такой вопрос: при сбрасывании памяти на диск, он всю сбрасывает или только обновившиеся участки? И, если только обновившиеся, то как происходит эта проверка?
MrShoor
21.03.2016 23:45А кто вам сказал что это утекшая память? Скорее всего firefox просто кеширует загруженные картинки и другие ресурсы, на случай если вы снова откроете закрытую вкладку. Данные можно будет достать из кеша и сразу вам показать. 1.5Гб адресного пространства — это ничего в масштабах например 16Гб системной памяти. И зная FF — скорее всего в about:config есть флажки, которые помогут избежать такого жадного кеширования.
Так что если говорим о утечках — то лучше брать код, и конкретно показывать, мол утечка вот здесь и вот здесь. А страшные циферки в диспетчере задач ниразу не показатель.dzavalishin
22.03.2016 00:55Вообще утечка памяти (адресного пространства) несущественна. Это утечка дискового пространства, которого вообще не жалко. Существенна утечка (разрастание) рабочего множества. В Фантоме, конечно. Хотя, по идее, в обычных ОС должно быть почти так же.
ScratchBoom
16.03.2016 21:12Дмитрий, интересно было бы узнать об общем состоянии работ над ФантомОС: Как ведётся разработка, кто занимается проектом, кроме вас? Нужна ли помощь проекту (я имаю ввиду разработческая). Что сподвигло к продолжению работ над ОС? Появились инвесторы?)
dzavalishin
16.03.2016 21:57+1Инвесторов не появилось, это по-прежнему некоммерческий опенсорсный проект.
Вернулся потому, что другой модели развития проекта пока нет, а уверенность в том, что это Фантом это правильно — есть.
У меня последние два года было жёсткое наслоение приоритетных задач — родился четвёртый ребёнок, шёл ремонт в квартире и на даче, бурно росла компания и менялась структура менеджмента, запускалось новое направление бизнеса — оказалось, что предел возможностям человека есть. :) Сейчас что-то из этого стабилизировалось, а отдых, как известно — смена вида деятельности, что и позволяет мне отдыхать с отладчиком в зубах час в день. Внезапно, это немало. :)
Помощь разработческая нужна. Очень. Присоединяйтесь.
blanabrother
16.03.2016 22:42Боюсь показаться профаном, но хотел бы задать вопрос. Какие нагрузки сможет выдерживать данный механизм? Имеется ввиду случаи многопоточной обработки данных с постоянной записью в оперативку. Интересная статья и мысли. Сложно представить как диск угонится за ОЗУ, а даже если накапливать diff, то в случае постоянной записи в ОЗУ и медленной записи на диск, буффер diff'ов просто переполнится, это неизбежно. Да и аварийное выключение приведет к потере накопленного буфера diff'ов.
dzavalishin
16.03.2016 22:53Размер diff-а не может быть больше физического объёма оперативной памяти. Ничего страшного.
dzavalishin
16.03.2016 22:58Немного более развёрнуто. Рабочее множество всех процессов (суммарный объём активно используемой оперативной памяти) или меньше ОЗУ — тогда дифф тоже меньше ОЗУ, или больше ОЗУ — тогда в традиционной ОС возникает пейджинг. В Фантоме он тоже возникает, но он является частью предварительного процесса формирования снапшота. То есть если страница памяти изменилась но была вытеснена на диск — её не надо записывать ещё раз, её просто включают в состав снапшота автоматически.
То есть — ни при каких условиях в момент формирования снапшота объём требуемого ввода-вывода не превышает размер ОЗУ (плюс размер метаинформации снапшота, конечно).
vanxant
17.03.2016 00:06Вот да, для тяжелой математики нужно уметь отключать персистентность, или давать возможность иметь и не-персистентную память.
Например, декодирование видео на процессоре. Нет смысла писать на диск каждый декодированный кадр.dzavalishin
17.03.2016 01:41Каждый декодированный кадр и так ни при каких условиях не будет писаться на диск. Они, как правило, декодируются каждый раз в один и тот же буфер. Иметь неперсистентную память несложно, но тогда программе придётся помнить об этом и обрабатывать пропадание содержимого неперсистентной памяти. Вот если бы потребовать для каждого такого куска иметь строго функциональный генератор, который ОС сама могла бы вызвать для восстановления участка. Небанально.
zzeng
17.03.2016 11:21Похожий вопрос, допустим, у меня матрица на несколько гигабайт и я её диагонализую (методом Якоби), много пишу, записи случайно распределены по адресному пространству.
Каждая конкретная страница меняется относительно редко, но в целом поток изменений огромен.
Как быть?dzavalishin
18.03.2016 13:07Всё верно, это — худший сценарий.
Никак.
Ну, то есть, диск будет страдать безмерно. На производительности машины, впрочем, это почти никак не скажется — нагрузка на процессор со стороны процесса снапшота почти никакая (сотни инструкций на страницу), а остальное — DMA и запись.
dzavalishin
18.03.2016 13:12Вообще такие вопросы — одна из причин, по которым я начал реализацию Фантома — к ним надо подойти и их порешать. Это могут быть разные варианты. Очевидный — уметь делать неперсистентные "анклавы". Что вообще легко и, практически, готово. Интереснее другое — уметь выделять в графе объектов замкнутые подмножества, для которых определять иные политики "фотографирования", но это — крайне небанально. Например, есть такой вариант подхода: уметь делать несколько параллельных виртуальных машин, которые видны друг другу условно прозрачно (как бы по сети), но имеющие обособленные адресные пространства и, соответственно, политики снапшотинга могут быть сильно разные. Это тоже интересный подход, но сильно тяжелее.
blanabrother
17.03.2016 09:02Т.е. пока снапшот не скинут на диск, продолжаете обновлять его, как только с некоторой периодичностью включается сброс снапшота на диск, вы его лочите, с этого момента создаете новый снапшот, который получает новые diff'ы, старый снапшот существует пока не записан на диск, как только записан — трете его. Так?
dzavalishin
18.03.2016 13:15В целом — да. Собственно, "обновлять его" — это просто работать в памяти. В остальном — всё точно так.
ComodoHacker
17.03.2016 15:23Может я чего-то не понимаю, но LXC и KVM поддерживают live migration уже давно. А коммерческие решения умеют и постоянно сохранять состояние, обеспечивая HA. И для этого вовсе не обязательно отказываться от концепции "файла".
dzavalishin
18.03.2016 13:21Ну, вы уж не браните меня так строго за то, что эти мысли пришли в голову не только мне и применяются в других системах. Так ведь бывает, я ж не могу запретить людям думать.
Но если Вам угодно видеть разницу, то она — принципиальна. Фантом гарантирует прикладным программам персистентную среду, что позволяет отказаться от файлов (или не отказываться) и за счёт этого удешевить разработку ПО и сделать его более гибким. А костыли этого не гарантируют.
А задача-то именно в этом — дать программисту среду, с одной стороны, достаточно привычную, с другой — позволяющую во многом упростить жизнь.
Вот CRIU — это действительно куда ближе. Опять же, они ставят другие цели, но в мои цели отчасти попадают тоже. Случайно. :)
tzong
19.03.2016 15:16Hewlett Packard Enterprise разрабатывает новую архитектуру под кодовым названием The Machine, главная идея которой — общая для узлов персистентная память. Возможно ли реализовать персистентную среду без необходимости сбрасывания снапшотов на диск? Ведь если память персистентная, диск больше не нужен.
23derevo
Надо тебя к нам на JUG/CodeFreeze снова притащить или на одну из конференций :)
dzavalishin
Летом? :)
23derevo
да хоть в марте-апреле! Очень круто, что ты снова взялся за Фантом.
dzavalishin
Интересно, что несколько проблем, которые казались просто неприступными, вдруг неожиданно разрешились. У меня из чужого кода были TCP/IP и USB stack, и в обоих колом стояли затыки, которые даже погружением в дебаггер на пару дней не были решены. А тут вдруг я их оба закрыл каждый за вечер. Взгляд "размылился", что ли...
23derevo
наверное. Отдохнул, переключился.