>> SU+J не относится к журналированию данных. Это механизм защиты метаданных и быстрого
>> восстановления места на диске, выделенного под запись новых данных.
> И чем это тогда принципиально лучше журналирования только метаданных в ext4/xfs/jfs/...
> ? Тем, что журнал отсутствует — вся магия SU переупорядочивания запросов на запись на носитель происходит в оперативной памяти, а J имеет такой маленький размер, что в случае аварийного завершения работы восстановление файловой системы занимает секунды, а не минуты проверок fsck, как у Ext*/XFS/JFS.
> Зато сами внутренности у UFS - архаичные и тормозные.
Зато Ext4 — это потомок Ext3, а Ext3 — это потомок Ext2, которая во времена изобретения UFS2+SU была такой же, как FAT. Со всеми вытекающими.
>> в том состоянии, в каком они были в момент сбоя.
> Это круто. Только что мне делать с жпегом из старой и новой
> половинок? И офисный документ из старой и новой части фиг прочтется.
Твои проблемы, что не записалось. Заведи полное журналирование метаданных и данных на Ext3/Ext4 — сравни по результатам надёжность с UFS2+SUJ: сколько "хвостов" обнаружишь в lost+found после внезапного вырубания питания там и здесь, какие файлы повреждены и может ли их восстановить fsck.
> Ну и так далее.
>> фоновой проверки при загрузке.
> Охренеть, простите, достоинство. В лине это умеют с доисторических времен ext3, jfs
> и прочие xfs'ы.
Ты правда не знаешь, что Ext3 нужно проверять fsck, отмонтировав том?
>> по сравнению с теми ФС, где таких "рамок" вообще нет (Ext2)
>> или они довольно зыбки (Ext3, Ext4).
> Теперь ты понимаешь зачем нам btrfs :). Там полное журналирование и оно
> не тормозит. Потому что журнал - вся площадь диска. В первом
> приближении.
>> FreeBSD во главу угла ставится надёжность и предсказуемость.
> Оно и видно - технологии защиты ядра и программ от атак почему-то
> даже в попсовых убунтах появились сильно раньше.
jail в Linux почему-то не наблюдалось до пиара LXC.
