>Ты вот как мантру повторяешь - более удачный, более удачный. А чем
>он более удачный? Может объяснишь коротенько? Более продуманными дисковыми структурами. В бтр-е идея CoW доведена до логичного финала - в стиле CoW-логики журнялятся как данные, так и метаданные. Для метаданных для этого пришлось разработать специфичные b-деревья, при том, IIRC, придумал это решение сторонний програмер а не оракловский архитект. Прикол в том что обычные b-деревья не годятся: там слишком много перетрясается при изменении дерева, что ессно портит всю малину(и тормозно, и много дряни писать придется если уж это CoW). Получилось относительно просто и универсально - CoW логика и для данных, и для метаданных. И, кажется, они первые кто допер до такого казалось бы очевидного фокуса. В итоге для ФС скажем не проблема делать постоянные снапшоты в момент (для них всегда все есть, и данные и метаданные - по сути достаточно лишь запретить GC их подтирание). И логика рекавери ФС проста как топор: просто лепятся автоматические снапшоты на ходу (раз уж это очень быстро). В случае аварии просто откатываемся до последнего автоматического снапшота и ... все. Да и быстрая запись как данных так и метаданных еще никому не вредила (двойная запись в CoW логике избегается, в отличие от традиционного журнала).
Тем не менее - лучше почитать описания разных ФС гденить в районе filesystems.nm.ru (подборку доков собрал местный спец по ФСам aka fresco) и сделать выводы самолично. Оно, конечно, грузновато, но интересно и не снабжено моими возможными ляпами.