> Да вот же её решение: http://www.dovecot.org/list/dovecot/2010-June/049918.html
> Проблема оказалась в кривом коде Dovecot.А кривой код в dovecot показать не изволишь? Проблема на самом деле не решена, и по моей ссылке от 2013 года всплывает уже в торрент-клиентах и прочих приложениях. Т.е. "кривой код" не в dovecot, а в реализации ZIL, видимо. На прочих несетевых FS всё работает прекрасно.
Что самое эпичное - в форках соляры тоже всплывает: 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)
Это и есть фатальный сбой контроллера/драйвера. Какой бы "непротиворечивой" ZFS в сферической теории в вакууме ни была - при сбоях той же адресации её ничего уже не спасёт.
> Если драйвер для железки написан криво, то
Хвалёная ZFS должна остаться "непротиворечивой" (основной козырь пиарщиков), нэ? Не остаётся. Значит толку от этой "непротиворечивости" - ровно 0.00.
>> Всё равно обязательно держать бэкапы,
> Ну ты понял... ;)
Именно. Что смысла в ZFS в текущей реализации чуть больше нуля - и так есть масса решений, не требующих угребищных костылей над VMM для своей работы.
> А какая ФС не пытается решить аппаратные проблемы своими силами, расскажи, а?
И какие же аппаратные проблемы пытаются решить ext'ы?
> zfs set primarycache=none poolname/rsubdfs
> zfs set secondarycache=none poolname/rsubdfs
Я сказал для БД, а не для тома. На томе кроме БД еще чего-то быть может.
> ZFS тоже интегрирована в систему и не требует костылей.
Особенно её кэш.
