По сути, если смотреть максимально обще, то фревый SostUpdates - это действительно такой специфический журнал, только существующий исключительно в памяти. И при сбое он теряется, то есть всегда выполняется rollback транзакций.

>McKusick указал на два основных недостатка:
>1) это сложность реализации (и соответсвенно отладки)
>2) возможность утечки свободного дискового пространства при сбоях
>Второй пункт рекомендует лечить фоновым fsck

Да, именно сложность реализации и составляет основную проблему, а сама идея неплоха. Второй пункт появляется, поскольку на диске реального журнала нет, и если сбой случится в окно записи на диск, то будет ошибка. Однако SU построен таким образом, что класс таких ошибок очень ограничен (по большому счету пропажа места, ага), потому с введением бэкграундного fsck систему можно запускать сразу же на непроверенной fs, очень удобно, в отличие от форсированных проверок "180 дней на ext3 без fsck". Журнал не панацея, хехе.

В общем, идея, повторюсь, неплоха, и вполне конкурентоспособна с журналом. Вот только из-за сложности реализации имеются проблемы - например в NetBSD с кодом задолбались и будут SU выкидывать. Печальный пример, как плохая реализация может убить хорошую идею.