ZFS, но не на linux.

Разваленных в хлам ext4 и ext3, в том числе и под постгресом, видел и чинил пару десятков случаев, xfs - 2 раза, оба без постгреса. Впрочем, xfs используют статистически реже.

256kScott TigerZFS, но не на linux.

на чем? какая хорошая комбинация?

1. Solaris
2. OmniOS, SmartOS
3. FreeBSD

https://omniosce.org вполне жив, смартос вполне можно применять как ОС общего назначения с некоторой несущественной спецификой.

А чего стрёмного? Как по мне, всегда лучше скомпилить самому, чем ставить непойми как собранные и работающие пакеты со стороны. Тем более что для Solaris и производных весьма показано обратно впиливать SysV shared memory, патч под это дело имеется https://smartos.org/bugview/MANATEE-371
Когда разбирался с этой проблемой, откровенно офигел от аргументации на удаление sysv из постгреса http://rhaas.blogspot.com/2012/06/absurd-shared-memory-limits.html - это просто каноническое проявление линапса головного мозга.

Собственно, возвращаясь к вопросу выбора ФС: постгрес целиком и полностью полагается на работу нижележащей ФС, а сама суть РСУБД предполагает, что потери и повреждения данных недопустимы. ФС - это вообще сложный и хрупкий механизм, его легко испортить и сложно или невозможно починить. В случае extN - повредить совсем несложно даже банальнейшей аварийной остановкой по сбою питания, NMI или кернел панике. Поэтому надо выбирать ФС, надёжность которой максимальна при сохранении удобства традиционной ФС общего назначения. Дальше под ФС выбираем ОС, где она нормально работает. У меня такая логика.

Leonid KudryavtsevScott Tiger....более что для Solaris и производных весьма показано обратно впиливать SysV shared memory, патч под это дело имеется....
а какие плюсы у SysV shared memory ?

Потребление памяти ядром на маппинги при использовании ISM. Почитайте по ссылке на патч для смартоса https://smartos.org/bugview/MANATEE-371

MelkijMVCC поверх CoW?..

А идея MVCC поверх вообще любой ФС Вас не смущает? :)

MelkijДохлых ФС в production не встречал.

Это говорит, скорее, о специфичности Вашего опыта на одной или небольшом количестве площадок. Когда площадок и их админов - многие сотни и на протяжении нескольких лет, поверьте - статистика совсем другая.

MelkijВот на тихо меняющую отдельные биты данных ECC (!) память - натыкался.

А как Вы это обнаруживали?

Leonid Kudryavtsev1) это или очень-очень-очень кривой китай должен быть
(сконструированный гениальным китайцем, что бы поменять битики и не спалиться на ECC)
2) или кто-то из "коллег" помог. Например каким нибудь джампером или настройкой в BIOS'а отключив ECC
3) упустили выгоду. Мне кажется, после такого шока, можно было бы к производителю сервера подать иск о "потерянной вере в человечество" и отсудить столько денег, что до пенсии бы хватило )))

Теоретически это могла быть ошибка сразу в нескольких битах (т.е., некорректируемая, хотя и бывают варианты ECC с коррекцией некоторых типов мультбитных ошибок) и кривая ОС, которая не пыталась воссоздать заново повреждённую страницу памяти или упаниковать при невозможности так сделать.

А как вам такой кактус - https://lwn.net/Articles/752063/ ?

Максим, тут нужно было бы уточнить, что «ядро» здесь - это ядро Linux, OpenBSD или NetBSD. Ядра рекомендованных мной ранее ОС данная проблема не затрагивает.

Partisan MБывает, и нередко, что советы в форумах поражают воображение.

OmniOS - только что узнал от вас о её существовании. ... Кстати, не только для меня, но и для PostgreSQL эта ОС неизвестна (ну, я только что узнал) - на сайте PostgreSQL нет дистрибутива для этой ОС и упоминания о ней. То есть, она неподдерживаемая для PostgreSQL. На сервере не следует пользоваться неподдерживаемым программным обеспечением.

Видите, как полезно для общего развития читать советы на форумах. Был рад хоть чуть, но расширить Ваш кругозор. Позволю себе ещё немного его разработать - на сайте postgresql.org дистрибутивы (в двоичном виде) есть только для Linux, все прочие дистрибутивы предлагается скачивать с посторонних сайтов. В то же время, читая файл INSTALL, можно наткнуться на следующее пояснение:


В build farm присустсвуют машины с OmniOS и SmartOS - см. https://buildfarm.postgresql.org/cgi-bin/show_status.pl , что делает OmniOS формально поддерживаемой сообществом разработчиков платформой, а Ваше мнение - ошибочным. В целом, я не вижу никаких проблем самостоятельно компилировать PostgreSQL на любых других и более экзотичных платформах.

Partisan MOpenSolaris. Хорошая операционная система. Но неперспективная. В прошлом году фирма Oracle втихомолку убрала большинство разработчиков OpenSolaris и процессоров Spark. Объяснений не дала, но видимо считает это направление для себя ненужным. Существующих пользователей будет поддерживать долго, но сомнительно, есть ли смысл связываться с OpenSolaris новым пользователям.

ОС OpenSolaris не развивается с 2010 года. Я не предлагал использовать такую ОС. SPARC пишется именно так. OmniOS и SmartOS - это то, во что превратился OpenSolaris силами сообщества и некоторых компаний.