На фоне какого-нить рейзер 4 пожалуй не предел мечтаний идиота =)
А так по моему нормальная ФС в плане соответствия ее сложности ее возможностям.

> Думаю, что простота во многих случаях - гарант надёжности и скорости,
> фичастость, как правило, ухудшает оба качества.

Хм... до некоторой степени согласен, НО вот например...
FAT - defective by design.Просто как топор.Но тормозно и с вагоном недостатков.Неактуален.
EXT2 - в базовом виде несложен.Только кому он в таком виде нынче нужен?Без журнала то и с тормозным проходом по каталогам.А если с журналингом, хешированием директорий и прочими фичностями - не такой уж он и простой...

И так почти везде почему-то - простые фс обычно почему-то медленные и тупорылые :\

Просто забейте диск на терабайт (нынче майнстрим смещается в сторону 750Гб дисков) и потом некорректно срубите питание разок.Потом расскажете, как вам время fsck у EXT2 :).Хотя-бы уж EXT3 тогда, а?И та не шедевральная.Плоховато по скорости, с рядом ограничений и устаревшим дизайном, структуры ФС занимают значительное место на диске, большие файлы удаляются долго, есть лимиты на число файлов в папке.Как системный раздел - сойдет.Как ФС для больших дисков - очень так себе.Просто на фоне остальных.

Это если ничего нет, ничего не нужно и всё это никогда не падает по питанию.

>Я просто не понимаю зачем мне может понадобится что-то другое.
>Возможно огромные серверы с raid и фанатичной заботой о надёжности
>требуют навороченыых ФС, но на десктопе ext2 - однозначный выбор.

Восьмилетней давности.

home:~> df
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              972M  345M  576M  38% /
udevfs                5.0M  160K  4.9M   4% /dev
/dev/md1               99G   55G   43G  57% /home
/dev/sdb1              10G  5.6G  4.5G  56% /usr
/dev/sda2             5.1G  712M  4.4G  14% /var
/dev/sdb6             350G  292G   59G  84% /var/ftp
/dev/sda6             350G  245G  106G  70% /media
/dev/sdc8             254G  242G   13G  96% /media/backup
/dev/shm              8.0G  338M  7.7G   5% /tmp
none                  272M     0  272M   0% /dev/shm

Припоминая, сколько мог fsck'ться ext2-раздел гигабайт на тридцать, мне становится дурно при мысли о том, сколько бы впустую лопатился на порядок больший объём.  Хранить рабочий MiniDV-материал на лентах не предлагать ;)

PS: для линуксового софтрейда в качестве "журнала" рекомендуется write intent bitmap, см. mdadm(8).

но представьте себе раздел, заполненный на 90% файлами средней величины в 30kb, объемом 2000Gb...
после этого сами начнёте искать альтернативы... а может и свою fs напишите.
в линухе это не так уж и сложно. вот и помелс есть... :-D (не в обиду...)

Это не просто RAID, это очень гибкий RAID :)
А снапшоты FS там могут параллельно работать как полноценные файловые системы, хотя зачем это?

Включи моск - емнип чтоб не надо было контроллеров и лвм"а :)

Например, на домашнем компе можно использовать аппаратный контроллер (пусть и дорогой), но, имхо, слишком геморно. Уже сколько раз с raid-z (типа Raid5) при ковырянии внутри компа (на гарячую) отключалось одновременно 2 диска (ненадежные контакты, это как никак не серверная железяка). Резет и все дальше работает как пить дать. Для полного удовлетворения scrub-ом пройтись и все как рукой снимает. Как это все лечить на аппаратном контроллере - ума не приложу.

RAID на уровне FS быстрее (файловая система знает что где лежит, да и перезаписываются при замене диска только нужные данные) и гибче (позволяет менять конфигурацию на лету, использовать разные диски).
Снапшоты нужны для бэкапов, апдейтов системы (которые можно откатить в случае неудачи). Удобно их использовать и для других вещей - например сборки нескольких версий программы из одних сорцов - создал файловую систему с исходниками, с нее наделал снимков и в каждом запустить make с нужными опциями.

методики и рассчёты где? почему гугл эту хрень не использует? видимо у них мало данных хранится

Мне в прошлый раз OOPSа хватило чтобы не делать таких вещей :).Надо б еще раз погонять но такого безрассудства от меня фиг дождетесь :P

>Так что для надёжных хранилищ

А в этом то качестве какие к btrfs предъявы?Ну насчет скорости снапшотов я еще понимаю но на именно надежности хранения то это не сказывается, только на времени создания бэкапа.

>Солярисному zfs - zfs FreeBSD или MacOS.

Это которые недоделаны то?Ага, хорошая альтернатива.После этого заявы советчика советующего недоделанный код про надежные хранилища выглядят каким-то понтом.Вот вы и пользуйте сырые ФС типа btrfs и zfs в бсд для ваших данных если они у вас столь неинтересные что и профукать можно.А я погодю их в продакшне юзать пока их релизом не заявят.Одно дело потестировать их а другое полномасштабно юзать.

Дык ни BTRFS ни ZFS для *bsd пока как релиз не заявлени и потому альтернатива они только для тех кто хочет их потестировать :).И кстати в упомянутом документе про структуры btrfs сказано что инкрементальные снапшоты сделать не вопрос.То что их СЕЙЧАС нет - да пофиг.Все-равно ФС недоделана еще и не релизного качества.У кого-то проблемы с пониманием того что такое "находится в разработке" и "готово для использования в продакшне"?