>Что-то я сомневаюсь, что она не теряет в скорости. Почему ты думаешь,
>что она должна быть быстрее обычной ФС c журналированием? В обычной ФС если честно журналить и метаданные ФС и данные файлов, придется писать записываемые данные 2 раза. Сперва в журнал, потом в ФС. Двойная запись данных разумеется сажает скорость записи. Зато честно реализуется "все или ничего".Запись аннулируется если обломалась при записи в журнал или доводится до конца по данным из журнала если обломалась уже при записи в основную ФС.
Обычно такая просадка считается неприемлимой (просадка вдвое, плюс-минус лапоть) и для большинства некритичных задач пользуют компромиссные варианты, когда в журнал идут только метаданные.Цена компромисса - честного "все или ничего" уже не получается.Валидное состояние ФС - да, есть.А вот в каком состоянии файлы?Правильно, никто ничего не гарантирует.Грамотный подход (типа ordered в ext3) может помочь данным оставаться более-менее корректными в типовых сценариях.Но честные транзакции через журнал надежнее.И этак вдвое тормознее...
"Версионники" пишут новые данные ОДИН раз.Как этакий "лог".Похожий по смыслу на лог журнала классической ФС.Из-за такого принципа работы "все или ничего" получается само (недописанные логи - в топку, дописанные - юзать, сконструировав из них текущий вид файла).При этом получается честное журналирование не только метаданных но и данных.И даже "машина времени" с разными версиями файла - просто свойство такой ФС(достаточно забить на логи позднее чем X - и вот вам ФС в состоянии на момент X).А запись вообще недеструктивна - исходный вариант файла вообще как правило не трогается (как минимум сразу, на момент записи).Отсюда вытекает и достаточно корректный откат (можно просто вернуться к прошлому состоянию файла на котором сорвалась запись) и богатые возможности по части снапшотов(все что надо для снапшота - уже существует).Минусы ... разгребать старье подтирая старые версии версионнику все-таки когда-то придется а сам этот процесс не то чтобы очень уж тривиальный.
