zfs дедупликация, уже готово?

что именно проделать?

Хочется бекапить ORACLE бекапы на том RAID1 md

А просто осилить rman backup level 1 не судьба? :-)

Есть еще пара багов(один я обнаружил сам и зарепортил), но мне они жить не мешают - они могут всплыть, если держать ZFS на корне

Ты про что именно?

Ну например на корне может вполне случиться вот это. Несмотря на корявое описание, относится оно не только к dd, как ты понимаешь...

А на более свежих версиях такое повторяется?

Ну это не отменяет моей задачи ведь. Ну и его я бекаплю несколько другой утилитой...

Готово во фре, но требования к памяти настолько запредельные, что лучше не включать
"...his means you should plan for at least 20GB of system RAM per TB of pool data, if you want to keep the dedup table in RAM, plus any extra memory for other metadata, plus an extra GB for the OS...."
http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe

Лучше манами обкурись. Ибо ты уже сделал минимум две ошибки: хочешь дедупликацию при малом количестве оперативки и хочешь зфс поверх рейда, что не рекомендуют разработчики.

Упадет не только wp, но и rp (потому что все через таблицы блоков будет делаться)

А уж как оно в линуксе себя поведет - вообще ни разу не понятно.

Не пробовал еще, но обязательно попробуй как руки дойдут

Готово во фре, но требования к памяти настолько запредельные, что лучше не включать

Сам устриц не ел, а мнение имеешь?

Дедупликация нормально отрабатывает с 8ГБ RAM и нескольких пулах в системе. Другое дело, что скорость I/O при этом проседает заметно.

DALDON опомнись какая там дедупликация если там вот такое https://github.com/zfsonlinux/zfs/issues/872 на каждом шагу

Сам устриц не ел, а мнение имеешь?

fbsd9, raidz, 4tb, 8GB mem, 40GB ssd cache ==>

Другое дело, что скорость I/O при этом проседает заметно.

Именно об этом и говорю, когда у тебя чтение/запись проседает до единиц мегабайт в секунду - дедупликация становится слегка не так нужна.

кстати zfsonlinux умеет TRIM на ssd?

Не вижу связи.

TRIM для ZFS взяли в FreeBSD HEAD из ZoL: http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036777.html

Слушай, а если дедупликацию включить, записать данные, а потом отключить, это как-то скажется на записанных данных?

В общем наверно не буду я с этим связываться. Дешевле будет купить два веника на пару террабайт, чем памяти кучу покупать, и переживать: а как оно там? :)

Слушай, а если дедупликацию включить, записать данные, а потом отключить, это как-то скажется на записанных данных?

Судя по проверке - нет, они так и будут дедуплицированы и работа с ними крайне замедлится.

и работа с ними крайне замедлится

А это-то почему? Если надо считать с диска блоки №1,2 и 3, какая разница, уникальны они или нет? А записываться должно уже без проверки хешей.

Видимо оно старые данные будет забирать по-прежнему из таблиц, но не грузить их в ОЗУ, а новые писать уже как обычно.

Если надо считать 100500 блоков, из которых физически записан только №48, то чтобы прочесть остальные 100452 блока, нужно 100452 раза подгрузить некислую таблицу в ОЗУ (предварительно выгрузив оттуда кеш) и найти в ней соответствие
1 - 48
2 - 48
3 - 48
...
49 - 48
etc

Нет. Но если потом такие данные попробовать, например, скопировать на этот же том - они будут скопированы по настоящему - дедупликация то уже отключена.