>> Да вот же её решение: http://www.dovecot.org/list/dovecot/2010-June/049918.html
>> Проблема оказалась в кривом коде Dovecot.
> А кривой код в dovecot показать не изволишь?

Похоже, ты даже по ссылке не прошёл.
///---
Here are fixes:

http://hg.dovecot.org/dovecot-2.0/rev/c24ee1ebb159
http://hg.dovecot.org/dovecot-2.0/rev/b2ffb6846973
---///

> Проблема на самом деле не решена, и по моей ссылке от 2013 года всплывает уже
> в торрент-клиентах и прочих приложениях.

Где конкретно?

> Т.е. "кривой код" не в dovecot, а в реализации ZIL, видимо. На прочих несетевых FS всё работает прекрасно.

С подавляющим большинством программ ZFS работает прекрасно. Может в консерватории кривого прикладного ПО что-то подправить надо?

> Что самое эпичное - в форках соляры тоже всплывает: http://www.kdump.cn/forums/viewtopic.php?id=736

Что "тоже"? По ссылке вообще другая ситуация, связанная с отзывчивостью.

> , что, в общем, и не удивительно - на соляре оно такой же костыль:
> "ZFS doesn't mix well with mmap(2). This is because ZFS uses the
> ARC instead of the Solaris page cache. But mmap() uses the
> latter. So if anyone maps a file, ZFS has to keep
> the two caches in sync."

И правда, неудивительно.

>> Да там не фатальный сбой дискового контроллера, а ошибка адресации пространства диска
>> за пределами 2 TB в драйвере mfi(4) (LSI MegaRAID SAS driver)
> Это и есть фатальный сбой контроллера/драйвера.

Это не сбой, а баг в драйвере.
Если калькулятор при сложении определённых цифр (например, "2") выдаёт неверные результаты ("2+2=5", "2+3=6" и .т.д.), а во всех других случаях ведёт себя адекватно ("3+4=7", "1+5=6" и т.д.), то это не сбой, это БАГ.

> Какой бы "непротиворечивой" ZFS в сферической
> теории в вакууме ни была - при сбоях той же адресации
> её ничего уже не спасёт.

А Ext* спасёт? А Btrfs спасёт? Сомневаюсь.

>> Если драйвер для железки написан криво, то
> Хвалёная ZFS должна остаться "непротиворечивой" (основной козырь пиарщиков), нэ? Не остаётся.

ZFS останавливает работу. Не видел что ли? И даже scrub запустили на смонтированном(!) повреждённом пуле. Сомневаюсь, что такое можно было произвести на искорёженной Ext4.

> Значит толку от этой "непротиворечивости" - ровно 0.00.
>>> Всё равно обязательно держать бэкапы,
>> Ну ты понял... ;)
> Именно. Что смысла в ZFS в текущей реализации чуть больше нуля -
> и так есть масса решений, не требующих угребищных костылей над VMM
> для своей работы.

У ZFS преимущество по управлению томами и квотами. Кроме того, она уменьшает время простоя из-за восстановлений данных из бэкапов, так как известно, какие именно файлы требуется восстановить.

>> А какая ФС не пытается решить аппаратные проблемы своими силами, расскажи, а?
> И какие же аппаратные проблемы пытаются решить ext'ы?

Не придуривайся! Классические ФС на SSD пытаются решить известно какие проблемы, так как CoW у них в зачатке или не реализован совсем.

>> zfs set primarycache=none poolname/rsubdfs
>> zfs set secondarycache=none poolname/rsubdfs
> Я сказал для БД, а не для тома. На томе кроме БД еще чего-то быть может.

Не различаешь файловую систему poolname/rsubdfs, выделенную для СУБД, от тома? Тяжёлый случай. :(
Впрочем, для тома — ZVOL — делается аналогично. Свойства ZFS primarycache и secondarycache для тома тоже действительны.

>> ZFS тоже интегрирована в систему и не требует костылей.
> Особенно её кэш.

Угу. Отдельный кэш на чтение L2ARC и вынесенный ZIL на SSD рулят и педалят так, что не снилось никаким костылям для Ext*. ;)