> Похоже, ты даже по ссылке не прошёл.
> ///---
> Here are fixes:
> http://hg.dovecot.org/dovecot-2.0/rev/c24ee1ebb159
> http://hg.dovecot.org/dovecot-2.0/rev/b2ffb6846973
> ---/// Слышал звон, но не знаешь, где он? По твоим двум ссылкам выше ничего, имеющего хоть малейшее отношение к багу ZFS+mmap+dovecot, нет. Там исправления сетевого кода. Учись читать то, что пишешь, прежде чем писать.
> Где конкретно?
Конкретно - сходи сюда:
http://thr3ads.net/freebsd-stable/2013/07/2662417-Help-with-...
Picard/flac, rtorrent
> С подавляющим большинством программ ZFS работает прекрасно. Может в консерватории кривого прикладного ПО что-то подправить надо?
Так и запишем - каждое прикладное ПО надо тестировать на совместимость с ZFS, потому что остальное - работает вовсе не с "подавляющим большинством", а везде. Итого: неэксплуатабельно. Ну, как уже говорил - источник виден: mmap, вот только mmap ныне не юзает разве что ленивый.
> Что "тоже"? По ссылке вообще другая ситуация, связанная с отзывчивостью.
Источник проблемы - один и тот же: костыль над VMM под названием ZIL/ARC. Проблема другая, причина - та же.
> А Ext* спасёт? А Btrfs спасёт? Сомневаюсь.
Не спасёт. Но не надо тогда говорить, что ZFS "защищена". Ни хрена она не защищена, во всяком случае, не более ext/btrfs в данном конкретном случае.
> ZFS останавливает работу. Не видел что ли? И даже scrub запустили на
> смонтированном(!) повреждённом пуле.
А толку? Данные всё равно в заднице - надо доставать из бэкапов.
> Не придуривайся! Классические ФС на SSD пытаются решить известно какие проблемы, так
> как CoW
Не обольщайся. Так как CoW реализован в контроллере, и так, как надо контроллеру. TRIM - это механизм связи между ФС и контроллером, вполне естественный в данном случае. В случае ZFS получим CoW-поверх-контроллерного_CoW, а это вполне себе снизит эффективность работы второго по мере заполнения драйва без очистки (даже при наличии TRIM). Так что ZFS на SSD только усложняет ситуацию. Для флешей есть F2FS, к слову.
> Не различаешь файловую систему poolname/rsubdfs, выделенную для СУБД, от тома?
В контексте вопроса, том - это отдельный namespace. Так же, как и тот красивый термин, который ты только что привёл. Различие в том, что у тома обычно имеется отдельно выделенный экстент на блочном устройстве (ну или минимальное количество оных), а у твоего варианта будем иметь еще и размешанные вместе с остальными по диску данные, добавляющие овердофига поинтов к уровню фрагментации.
Спрошу в лоб тогда: таки для отдельных файлов выключить CoW реально, или нет? Надо редко, но надо. Разработчики BTRFS вполне себе понимают, зачем это может понадобиться.
> Угу. Отдельный кэш на чтение L2ARC и вынесенный ZIL на SSD рулят
> и педалят так
Что стоимость решения увеличивается раза в 2-3, при аналогичной производительности. А если выкинуть костыли и взять родную для ZFS ОС - то и раз в 20-30.
