Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2009-09-09 23:19:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Фантом раз, фантом два...
     Я всё о Фантоме. Который "от dz".

     ОС Фантом настолько сурова, что в ней нет файлов. Документ, с которым в данный момент работает пользователь, даже в обычных операционках во время работы не "лежит на диске", а висит в памяти в виде пучка объектов. Система (Фантом), в силу, тсзть, дизайна, гарантирует долговременную сохранность состояния приложения (и, естественно, всей этой грозди объектов) - а раз так, то как бы нет потребности эту гроздь объектов переливать из одной формы (память) в другую форму (последовательность байт), и обратно. Привязали к этой грозди иконку на десктопе - пользователь кликает иконку, у него всплывает документ - красота, и никаких файлов!
     С точки зрения dz, отсутствие файлов, а равно и отсутствие необходимости чего-то куда-то сохранять, есть плюс разработчикам: не надо писать процедуру разборки "внешнего" формата "документа" во внутренний формат "как оно лежит в памяти", не надо писать обратную процедуру - сборки внутреннего представления в поток байтиков. И это как бы верно. Если бы не одно "но" - даже сам dz понимает, что без файлов, собственно, обойтись всё равно не удастся - мир вокруг, увы, слишком завязан на "одномерные потоки данных", и даже при передаче документа между двумя "фантомами" в промежутке может возникнуть какой-нибудь ужас, типа флэшки с FAT'ом, электрописьма с аттачем, или банального веб-сайта с пипкой "download". И тут-то файл и понадобится.
     Но это фигня! Если документ - не более чем "состояние приложения" (т.е. фактически множество объектов, принадлежащих приложению, плюс совсем чуть-чуть служебной информации, а может быть и без неё), то сохранение/загрузку документа можно сделать единообразным образом, и вообще поручить её системе: нужно сохранить документ - просим систему сделать "дамп состояния программы", нужно загрузить - просим "восстановить состояние из дампа". Дамп - обычный файл, который можно передавать куда надо, разработчику приложения думать ни о чём не надо - достаточно дёрнуть ровно одну ниточку в системе, а бонусом - вместе с документом при этом автоматом будет сохраняться всякая приятная мелочёвка типа undo-буфера и запомненных строчек в полях ввода. Недостатки тоже есть, но они решаемы :-)
     Есть только один нюанс. Для того, чтобы сохранять "гроздь объектов" - вовсе не нужен фантом. Никто не мешает приделать такую возможность к любому современному "объектно-озабоченному" языку. Более того - в принципе это приделываемо к любой программе, необязательно "объектно-ориентированной" - просто "объектом" там будет нечто другое. И мы поимеем один из бонусов фантома (заментый, правда, скорее разработчикам чем пользователям), не имея собственно фантома.

     Второй бонус Фантома (заметный пользователю, а не разработчику) - возможность "упасть-отжаться": прозрачное (без остановки приложений) постоянное "автосохранение" мгновенного слепка состояния системы (и приложений). Радость при этом в том, что даже при внезапном пропадании электричества - теряется не "вся работа с момента последнего сохранения", а только последние несколько минут, а то и секунд: после загрузки системы она восстанавливается по состоянию "на момент последнего снапшота". При этом для снятия снапшота, напомню, не требуется остановка приложений.
     Как это реализовано - особо не афишируется. Но, как мне кажется, особо фантазировать не получится. В момент начала снятия снапшота мы выставляем всем "объектам" флажок "не сохранён". Далее - бежим по всем объектам, сохраняя их, и сбрасывая флажки. Если приложение хочет изменить (записать в) какой-то объект, помеченный как "несохранённый" - система автоматически делает copy-on-write - дублирует объект, приложение начинает работать с объектом, а система, когда дело доходит до сохранения именно этого объекта, сохраняет копию (и убивает её - у нас остался оригинал). На самом деле всё чуть сложнее - снапшоты надо делать инкрементально (т.е. к объекту привязать что-то вроде dirty flag, и при его чистоте - не пересохранять объект, а делать ссылку "старая копия вполне годна"), снапшота должно быть два - один "в стабильном состоянии", второй "в процессе сохранения", а "флажки сохранённости" необязательно тупо переворачивать у всех объектов, достаточно в начале цикла сохранения переопределить их интерпретацию на противоположную. Впрочем, это подробности.
     Многие программы сами имеют функцию автосохранения. Полезную - когда документ небольшой, и жутко раздражающую, когда документ разрастается на сотни мегабайт и сохраняется минутами. Раздражающую ровно потому, что на время сохранения программа блокируется - действительно, сложно одновременно сохранять текущее состояние, и вносить в него изменения.
     Однако - опять вспомним фантом. Ничего не мешает делать фантомовское "прозрачное сохранение" в пределах одного отдельно взятого приложения. Механизм тот же - сохранение всего по кругу, CoW для несохранённых объектов при попытке их изменения, инкрементальность сохранения. После этого "автосохранение" в данном приложении начнёт работать волшебным образом: если я сижу и набираю текст (изменения - не более десятков байт в секунду) - автосохранение будет успевать сохранить изменения буквально в реальном времени, и только если я делаю большие изменения - автосохранение будет "отставать" на заметное время. В любом случае меньшее, чем обычное автосохранение всего документа "раз в пять минут", и не блокирующее на это время приложение. А заодно и обычное, не автоматическое, сохранение станет халявой: просто прекратили изменять документ, дождались конца цикла автосохранения, выдали окошко "всё ок" :-)
     Правда, есть нюанс: для достижения такого счастья в обязательном порядке понадобится поддержка со стороны языка программирования (среды выполнения, возможно даже системы). Поскольку, как мне кажется (могу ошибаться), на современных языках подобные извраты с CoW естественным образом не пишутся, а противоестественные методы - угробят идею в зародыше. Но, опять же, это возможно и без создания новой ОС - модернизацией уже существующих.

     Поэтому, я так подозреваю, где-нибудь в windows 8 или windows 9 мы вполне можем обнаружить "бессмертные" приложения или "прозрачное" сохранение. Файлы, надеюсь, останутся на месте: микрософт - не Завалишин, на такие радикальные меры не пойдёт :-)


(Читать комментарии) - (Добавить комментарий)


[info]dibr@lj
2009-09-10 06:37 (ссылка)
Не трави душу. Мечты, понимаешь.
Хрен знает когда, лет пятнадцать назад если не больше, сидел на СМ-4 с ОС RSX-11 (если не перепутал название). Жесткие диски системы "стиральная машина" и ёмкостью с пачку трёхдюймовых дискет... и на этом - FS с автоматической поддержкой версий файлов! Прозрачной абсолютно: если не знать, так и не заметишь - всегда по умолчанию используется последняя версия, но если сделать определенное телодвижение - получишь любую из (сохранившихся - диски-то маленькие) предыдущих.

Прошло N-дцать лет, объемы дисков выросли на несколько десятичных порядков. Где, %$#, современные FS с автоматической поддержкой версий?! Ужас...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-09-10 07:14 (ссылка)
Отступление по поводу версий.

История и бэкап с версиями сейчас можно сделать с помощью Windows Home Server. Это такой offline вариант. Там можно настроить бэкап выбранных компонент файловой системы (хоть все) по расписанию. Предлагают делать каждую ночь. Фишка в том, что они хэшируют фрагменты файловой системы на уровне секторов, т.е. если будут совпадающие файлы на одном диске или даже на нескольких машинах в сети, то они не будут дублироваться. Соответственно инкрементальный бэкап идет шустрее и уже не требует много места. Потом ты можешь зайти и посмотреть копии своих файлов и посмотреть на историю, скопировать оттуда то что надо или стартовать со специального диска который из WHS вынет снапшот твоей системы и просто перепишет его поверх твоей.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-09-10 07:25 (ссылка)
> История и бэкап с версиями сейчас можно сделать с помощью Windows Home Server.

Если я правильно понимаю - нельзя. "Система версий" и "автоматический бэкап" - совершенно разные версии, у них даже цели разные. Хотя некоторая похожесть есть, да.

> Предлагают делать каждую ночь.

Пишу я, понимаешь, программу. И в процессе писания обнаружил в ней ма-аленький, не очень критичный, глюк. В процессе исправления которого буквально за десять минут насажал столько изменений, что программа вообще перестала запускаться, и её явно проще "замазать чем отскоблить" - откатиться назад на десять минут, и начать заново. Пример, замечу, из жизни - счётные задачи они такие, тут тронул - там упало, там поправил - весь расчет вразнос пошёл, и это не "ошибки программы", это "особенности работы алгоритма".
Как WHS позволит мне восстановить версию файла по состоянию на десять минут (и десять сохранений) назад? Вчерашнюю не надо - я утром в неё довольно много понаписал, терять как-то не хочется.

(Ответить) (Уровень выше)


[info]dibr@lj
2009-09-10 07:34 (ссылка)
> "Система версий" и "автоматический бэкап" - совершенно разные версии,

"Разные системы". конечно. Как "страховочный пояс" и "страхование жизни" :-)

И ещё. Версионность - свойство FS. WHS - отдельная железяка. Прикрути её к ноутбуку, с которым я сижу в поезде и что-то пишу?...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-09-10 07:51 (ссылка)
Все понимаю. Это по сути просто инкрементальный бэкап по расписанию. Плюс его в том, что они умеют распознавать дублирующиеся секторы и при бэкапе нескольких машин или одинаковых файлов существенно могут сэкономить время.

А вообще версионность можно сделать в ntfs через shadow copy (через него же работает transactions, объединяя группы изменений в snapshot). Но только вопрос в том, кто будет активировать точку с версией. Если эту фишку добавить в процедуру сохранения документа (стандартный диалог например) и все будет замечательно.

http://en.wikipedia.org/wiki/Shadow_Copy

утилита для просмотра истории
http://www.shadowexplorer.com/documentation/manual.html

В vista есть вроде специальная закладка previous versions.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-09-10 07:57 (ссылка)
А "стандартной процедуры сохранения"-то и нету :-) Вот я нажал ctrl/s в ворде или F2 в фаре - к чему цепляться будем? ;-) А если приложение решит само озаботиться версиями - то оно может и без поддержки ОС это сделать. "Предыдущую версию" почти все программы сохранять умеют, добавить настройку "хранить N версий" - и всё готово. Но приложение должно этим озаботиться, а если нет?

С другой стороны - наверное можно перехватить API "открыть файл", и пытаться создавать версии в этот момент. Но глючно это по-моему...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-09-10 08:58 (ссылка)
>С другой стороны - наверное можно перехватить API "открыть файл", и пытаться создавать версии в этот момент. Но глючно это по-моему...

Да если ты хочешь на уровне файловой системы так делать, то так и надо примерно - Open, write..., close - такая цепочка должна приводить к созданию копии. Но если вдруг программе вздумается каждую секунду или может даже чаще что-то таким образом дописывать в файл, то будет плохо. Тут бы по идее надо API менять - нужно качественное изменение оформлять как транзакцию, тогда уже можно легко прикрутить фигню которая эту транзакцию будет складировать в версию.

***

Еще кстати есть толком неразрешимая проблема с файлами - хранение дополнительных метаданных. Это может быть: тэги к музыке, тэги к видео (их кстати нет!), к картинкам всякие дополнительные данные типа EXIF, просто ключевые слова и пр. Если это и прикрутить ко всем файлам в виде расширенных атрибутов (NTFS например), то при передаче за пределы NTFS атрибуты потеряются. Если копировать не системной функцией CopyFile, то тоже потеряются, если делать преобразование формата (например bmp -> jpeg какой-нибудь обычной утилитой то расширенные атрибуты тоже потеряются). Вобщем нельзя так сделать чтобы все везде работало и получается что иногда проще рядом положить файл с описанием и его ручками таскать следом.

Здесь выход правильный тоже в API - надо эту абстракцию было сразу вводить и тогда все бы не забывали ее перетаскивать и учитывать, но сейчас это малореально.

(Ответить) (Уровень выше)


[info]dz@lj
2009-09-10 13:19 (ссылка)
кстати, именно из RSX я в фантом хочу притащить тему версионности классов (кода).

(Ответить) (Уровень выше)


[info]balamutang@lj
2009-10-15 14:45 (ссылка)
>Прошло N-дцать лет, объемы дисков выросли на несколько десятичных порядков. Где, %$#, современные FS с автоматической поддержкой версий?! Ужас...

такая фича в windows серверных и в некоторых версиях висты при включении теневых копий например есть.
http://www.winline.ru/articles/2742.php

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-15 16:27 (ссылка)
Если я правильно понял, то это даёт возможность восстановления состояния файла не вида "ой, $%#, я все сломал, хочу предыдущую версию", а "хммм, по-моему у нас проблемы. Когда у нас было последнее создание точки восстановления, пять дней назад?"...

В RSX-11 "старая версия" сохранялась при _каждом_ сохранении файла. Грубо говоря, пару раз внёс изменения/сохранил, убедился что "всё сломалось", откатился "на три сохранения назад", работаешь дальше. Тут - из статьи неочевидно что можно откатиться ближе чем на последнюю "точку восстановления", и что точки восстановления могут делаться настолько часто, что можно откатываться на малое время назад.

Хотя, возможно я невнимательно читал :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]balamutang@lj
2009-10-15 16:53 (ссылка)
ну по сути то да - копии (хотя тут больше подходит слово снимки) делаются по расписанию, но сам процесс создания теневых копий занимает достаточно мало ресурсов.
есть практика на файловом сервере запускать этот процесс 3 раза в день и все это абсолютно прозрачно для пользователей.
По идее на выделенном разделе с документами/исходниками можно увеличить частоту хоть до одного раза в пять минут и в принципе этого будет достаточно для отката.

(Ответить) (Уровень выше)


(Читать комментарии) -