BTRFS...

Переводи свои почтовые ящики на FreeBSD с ZFS.

LVM+xfs(ext4)

Я хоть и люблю и использую на ноутбуке btrfs, для критичных сервисов предпочитаю более проверенные решения.

Снапшоты на LVM нельзя хранить... Очень сильная деградация производительности на запись даже с одним, а уж если их будет 3-5, то боюсь что запись вообще встанет. А ZFS на линуксе еще не?

если есть 4 гб оперативы на тб дискового пространства, то используй.

А ZFS на линуксе еще не?

Очень даже да, на предыдущем проекте вовсю использовали (Ubuntu).

упорина прими

SSD бы тебе купить надо, барин...

Вобщем глядя на это дело, я все-таки решил, что ну его в пень и поехал на xfs.

Все правильно сделал, я считаю. XFS под почту - идеально

а тут мне пара экспертов рассказывала, что скорость работы с мелкими файлами на ней починили

Таки да, и давно уже. На чтение у неё вообще никогда проблем не было, а запись поправили в ядрах 2.6.3х

Лью ящики - наблюдаю переодические I/O Error. Пока удается обходить, поднимая соотсветствующий индекс из снапшота. Однако вчера вечером проскочила ошибка чтения и из файла данных. В опциях монтирования ничего особенного нет, только сжатие. Внезапных отключений за время использования не было ни одного. Ядро 3.19. Не готов btrfs, совсем не готов еще.

Под почтовую базу?? Зачем?

4 гб оперативы на тб дискового пространства

Из пальца высосал?

btrfs Под почтовую базу?? Зачем?

а разве не столько надо при использовании дедупликация и инкрементных снапшотов?

lz4 и сказочно всё работает, мы кстати так и не узнали не дистрибутив, не ядро ничего, может у него там ядро 2.6....

ах, для снапшотов. но ЛВМ же

lz4 это архиватор

а разве не столько надо при использовании дедупликация

Нет не столько. И дедупликацию лучше вообще не использовать.

инкрементных снапшотов

Это не имеет никакого отношения к потреблению памяти zfs.

О_о и давно дедупликацию не надо использовать?

btrfs Под почтовую базу?? Зачем

Дедупликация, сжатие. Снапшоты. (Дедупликацию пока не включал, только протестировал)

ах, для снапшотов. но ЛВМ же

См. выше -

Снапшоты на LVM нельзя хранить... Очень сильная деградация производительности на запись даже с одним, а уж если их будет 3-5, то боюсь что запись вообще встанет.

Ядро 3.19, куда уж свежее.

дистрибутив?

убунта 14.04

вот и нашлась причина, раз всё равно будешь переустанавливать, возьми fedora/centos 7, на бубунте вечно проблемы которых нет в других местах.

Оперативку проверял?

это виртуалка, похостил ее на разных машинах за это время - глюки одинаковы. Так что память тут вряд ли...

сделай тоже самое только на fedora, проблемы не будет.

я внизу «похожие темы» почитал, твою любовь к дебам понял. При случае попробую на шапке.

А btrfs на хосте стоит в качестве хранилища или на госте? И что за виртуализация?

На госте конечно. На хосте HyperV (чую, щас мне гарантировано найдут козла отпущения))))

давно дедупликацию не надо использовать?

Никогда не надо было использовать, пруф - http://habrahabr.ru/company/hostkey/blog/179151/

Никогда не надо было использовать

смотря, что за задачи, не? я сам, если что, не сторонник дедупа(нексенты, впрочем, тоже), но в паре проектов была реальная польза от этого.

смотря, что за задачи, не?

Возможно.

Ничего не говорят в инете про btrfs и Hyper-V, но зато много говорят про ext3 Hyper-V, и то что ей очень желательно подавать vhd/vhdx не расширяемый и размер блока файла не стандартный делать 32мб, а уменьшать до метра. А лучше вообще не юзать. Ибо пишет она почутьчуть в разные места и получается что каждый раз по 32 метра пишется. И что-то мне кажется что у btrfs патерн записи тот же.

Спасибо за информацию! В принципе это действительно может быть причиной. Но от hyper-v в инфраструктуре уходить пока не хочу, буду тестировать это дело в разных ключах.

Я как бы за это и не ратую. Просто btrfs себя очень плохо зарекомендовала на KVM (тупняки ввода/вывода, которые воспринимаются гостем как ошибки ввода вывода) и поэтому юзать её в другой системе виртуализации весьма рисковано.

Перешел на maildir расположенный на xfs (был mdbox + sis). Поджал его gzip'ом средствами самого dovecot (выигрыш объема получился около 40%). На выходе получилась прекрасная производительность, я даже удивился. И удобство бекапов и восстановлений. Стабильность пока отличная. Я доволен :)