The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Обзор файловой системы NILFS2, которая будет включена в сост..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Отдельный RSS теперь доступен для каждого обсуждения в форуме и каждого минипортала.
. "Обзор файловой системы NILFS2, которая будет включена в сост..." +3 +/
Сообщение от User294 (ok), 04-Июн-09, 02:01 
>но как я понимаю, версионные ФС создают большую избыточность данных, чтобы хранить
>одни и те же файлы, но разных версий.

Версионники не переносят логи изменений из журнала в основную ФС(в отличие от обычных).Вместо этого вся ФС просто является кучкой логов.В результате достигается вполне логичная экономия: запись изменений делается 1 раз - в лог.А переносить из лога в основную ФС - не требуется.Экономия по операциям записи и рост скорости записи - очевидны.

При этом можно считать что ФС постоянно себя снапшотит(за счет ее структуры "куча логов" можно восстановить не только текущее но и некий набор прошлых состояний).Всегда есть набор "кандидатов в снапшоты" - в терминах NILFS это "чекпойнты".Что-то типа снапшотов, только временных - их живет некая пачка, самые старые постепенно подчищаются garbage collector'ом для как раз очистки места на диске.Т.е. выводок временных снапшотов живет на ФС чисто за счет принципа ее работы - ФС логгит все что делает, всегда можно выхватить состояние на некий предшествующий момент просто забив на более новые логи.Что и позволяет просто и корректно восстанавливаться после краха, откатываться на прошлые версии некоторое время и т.п.. Сказать что это занимает место можно достаточно условно - старые чекпойнты постепенно прибиваются и как максимум про них можно сказать "временно занимают место".

Создание "постоянного" снапшота из временного чекпойнта = запрету стирать некий набор логов, т.е. просто, быстро и нахаляву, ведь все что было надо для снапшота - уже есть, просто garbage collector-у запрещается прибивать нужные логи когда-то там в будущем.Это, разумеется приводит к съеданию места таким снапшотом - чудес не бывает.А вот временные чекпойнты место занимают достаточно условно.Тем не менее, хоть они и временные, они позволяют некоторое время (пока их не убьет GC) откатываться к старому состоянию.

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

Эта разница называется "логами".Вся ФС состоит из "разниц" в виде логов.Новое состояние = старое + логи.Инкрементальность зашита в принципах работы такой ФС :)

>правильно понимаю?

Да - такая ФС "разницами" и оперирует, потому и log structured.Из логов состоит.

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

Минусов у такого подхода как я понимаю есть - срач логами по всему диску и нужда их постепенно подтирать.Потенциально может быть фрагментация + требуется достаточно непростой garbage collector и достаточно навороченная логика вокруг всего этого.

ЗЫ если я где-то наврал, пусть гуру типа Фрески меня поправят.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Обзор файловой системы NILFS2, которая будет включена в сост..., opennews, 03-Июн-09, 23:31  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру