Исходное сообщение
"Представлен проект OpenZFS, направленный на  унификацию разв..." Отправлено iZEN, 28-Сен-13 17:01
> Верифицировалась-верифицировалась, да не выверифицировалась. > --- > http://lists.freebsd.org/pipermail/freebsd-stable/2013-July/... - проблема > ZFS/BSD/mmap, давно (с 2010!!! http://www.dovecot.org/list/dovecot/2010-June/049631.html) > известная, и хрен до сих пор пофикшенная. Да вот же её решение: http://www.dovecot.org/list/dovecot/2010-June/049918.html Проблема оказалась в кривом коде Dovecot. > http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/... - как? > Щито? Верификация и непротиворечивость от фатальных сбоев дискового контроллера не спасают? Да там не фатальный сбой дискового контроллера, а ошибка адресации пространства диска за пределами 2 TB в драйвере mfi(4) (LSI MegaRAID SAS driver): http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/... http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/... > (это такой жесткий капитанинг, ибо всем, кроме упоротых, понятно) Данные записаны > успешно, а после записи благополучно потеряны старые? Т.е. в эксплуатации - > всё равно разворачивать бэкап, ибо риск потери остаётся. "Тогда зачем платить > больше" (с)? Если драйвер для железки написан криво, то кто виноват, разработчики файловой системы или драйверописатели? Сам подумай. Включи логику. > Это я к тому, что в эксплуатации по надежности ZFS ни разу не лучше прочих систем, как бы её ни пиарили. Лучше, если сквозная целостность данных поддержана непротиворечивой программной реализацией драйверов. А то так можно дойти до того, что из /dev/random получать всё время одно и то же число независимо от того, сколько раз вызывать. > Всё равно обязательно держать бэкапы, Ну ты понял... ;) > и всё равно обязательно применение рук при анализе > сбоев. Хреновость вижу в том, что она еще и ряд сбоев > скрыть пытается, но это уже на вкус и цвет. А какая ФС не пытается решить аппаратные проблемы своими силами, расскажи, а? fsck (если работает) в ваших ФС вообще не знает об именах файлов и набьёт потерянные цепочки в /.lost+foud в кучу — сиди и разбирайся по содержимому. :)) В ZFS хотя бы знаешь, что конкретно потеряно среди терабайтов уцелевших данных. > Снапшоты и прочие вкусности - это да, пока да. Вон btrfs уже > почти production ready (дистры начинают переползать), его активно обезбаживают, нашпиговывают вкусными фичами достаточно модульно > отключите мне кэш для БД выборочно в ZFS? zfs set primarycache=none poolname/rsubdfs zfs set secondarycache=none poolname/rsubdfs >, он не требует никаких навесных костылей для работы, и - > самое главное - мейнстримовый, т.е. прекрасно интегрирован в систему. ZFS тоже интегрирована в систему и не требует костылей.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Верифицировалась-верифицировалась, да не выверифицировалась. >> --- >> http://lists.freebsd.org/pipermail/freebsd-stable/2013-July/074347.html - проблема >> ZFS/BSD/mmap, давно (с 2010!!! http://www.dovecot.org/list/dovecot/2010-June/049631.html) >> известная, и хрен до сих пор пофикшенная. > Да вот же её решение: http://www.dovecot.org/list/dovecot/2010-June/049918.html > Проблема оказалась в кривом коде Dovecot. >> http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/015575.html - как? >> Щито? Верификация и непротиворечивость от фатальных сбоев дискового контроллера не спасают? > Да там не фатальный сбой дискового контроллера, а ошибка адресации пространства диска > за пределами 2 TB в драйвере mfi(4) (LSI MegaRAID SAS driver): > http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/015587.html > http://lists.freebsd.org/pipermail/freebsd-fs/2012-November/015589.html >> (это такой жесткий капитанинг, ибо всем, кроме упоротых, понятно) Данные записаны >> успешно, а после записи благополучно потеряны старые? Т.е. в эксплуатации - >> всё равно разворачивать бэкап, ибо риск потери остаётся. "Тогда зачем платить >> больше" (с)? > Если драйвер для железки написан криво, то кто виноват, разработчики файловой системы > или драйверописатели? Сам подумай. Включи логику. >> Это я к тому, что в эксплуатации по надежности ZFS ни разу не лучше прочих систем, как бы её ни пиарили. > Лучше, если сквозная целостность данных поддержана непротиворечивой программной реализацией > драйверов. А то так можно дойти до того, что из /dev/random > получать всё время одно и то же число независимо от того, > сколько раз вызывать. >> Всё равно обязательно держать бэкапы, > Ну ты понял... ;) >> и всё равно обязательно применение рук при анализе >> сбоев. Хреновость вижу в том, что она еще и ряд сбоев >> скрыть пытается, но это уже на вкус и цвет. > А какая ФС не пытается решить аппаратные проблемы своими силами, расскажи, а? > fsck (если работает) в ваших ФС вообще не знает об именах файлов > и набьёт потерянные цепочки в /.lost+foud в кучу — сиди и > разбирайся по содержимому. :)) В ZFS хотя бы знаешь, что конкретно > потеряно среди терабайтов уцелевших данных. >> Снапшоты и прочие вкусности - это да, пока да. Вон btrfs уже >> почти production ready (дистры начинают переползать), его активно обезбаживают, нашпиговывают вкусными фичами достаточно модульно >> отключите мне кэш для БД выборочно в ZFS? > zfs set primarycache=none poolname/rsubdfs > zfs set secondarycache=none poolname/rsubdfs >>, он не требует никаких навесных костылей для работы, и - >> самое главное - мейнстримовый, т.е. прекрасно интегрирован в систему. > ZFS тоже интегрирована в систему и не требует костылей.
	Введите код, изображенный на картинке: