>>что LVM обеспечивает снапшоты, то почему же нельзя считать, что gjournal
>>обеспечивает журналирование?
>
>Вообще за журналирование посчитать это можно.Но это строго говоря не фича ФС
>в меру моего понимания - даже назвать фичой UFS слишком жирно.Конечно, gjournal -- не фича ФС, так как это класс модульной системы GEOM (ага, unix-way во всей красе). Это слой (provider) для обеспечение журналирования файловой системы UFS2 на потребляемых (consumer) устройствах хранения. То есть файловая система создаётся (форматируется newfs) на специальным образом подготовленных носителях, а не наоборот, как в Linux, "накатывается" журнал.
>Кстати
>любопытно насколько такое журналирование эффективно в плане скорости.Вот тут есть подозрение
>что ФС зная какие у нее структуры и какие из них
>критичны может журналировать куда оптимальнее.
Как настроишь -- так и будет. Журнал занимает порядка 1 гигабайта для одного раздела (неважно, сколько места занимает сам раздел с UFS2). Кроме этого, журнал можно хранить на отдельном устройстве. Для увеличения быстродействия используется опция "async" при монтировании журналируемого раздела. Ограничения на размер раздела UFS2 обусловлены слоем абстракции FFS (до ~1ТБ).
>Лично мне вообще кажется наиболее разумным и
>перспективным журналирование путем версионирования - мало того что при этом откатить
>неуспешную транзакцию не вопрос так еще и версионирование старых версий файла
>по сути чуть ли не нахаляву получается (если я не путаю,
>это то что называется термином copy-on-write).Ну а это как я понимаю
>не про gjournal
Такое реализовано в ZFS.
OpenSolaris последней сборки имеет на борту Nautilus'a ползунок, позволяющий откатить изменения в текущей папке на несколько шагов назад.
>А бсдшники похоже бездумно парировали проблему первым подвернувшимся под
>руку методом.Далеко не факт что это наиболее оптимальное решение на данном
>этапе развития технологий.Если смысл существования LVM мне понятен то вот про
>такое журналирование UFS я бы такого не сказал.
Тебе просто непонятен смысл GEOM.
