Блочная дедупликация в Linux

zfs же, не?

Буду краток: ZFS. Использовать в качестве ядерного модуля и создавать не файловые системы, а ZVOL-ы - блочные устройства, поверх которых можешь пилить какую угодно ФС(в примере по ссылке пилят б-гомерзкую NTFS).

А зачем поверх zvol чужие fs,когда своя есть?

Да, про него я, как ни странно, вспомнил только после того как топик налабал :)

Фс мне вообще не нужна, я хочу экспортировать это дело по фиберченнелу или айскази. Завтра попробую погонять зфс в плане иопсов и скорости с врубленой дедупликацией.

Завтра попробую погонять зфс в плане иопсов и скорости с врубленой дедупликацией.

Без кеширующих устройств и на объемах >1TB я даже знаю результат этих замеров.

http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe

zfs

btrfs, выполняется утилитой bedup

в zfs дедупликация тоже есть, но только онлайновая (насколько я помню), а это многократный расход оперативки - цифры легко гуглятся

к тому же zfs - это не для linux

гоняю zvol по iscsi и отдаю диски виртуалкам, только вот не на linux, zfs живет на freenas, только вот всегда использую сжатие, а дедупликацию вырубаю.

попробую погонять зфс в плане иопсов и скорости с врубленой дедупликацией.

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

Да, я рассчитывал что дедупликация жрёт много памяти, но 30Гб на 1Тб данных это как-то.. эээ.. много.

320 байт на блок в таблице дедупликации - куда им столько? Хэш SHA256 этого блока занимает 32 байта, чем они остальное забивают?

У меня тут просто на горизонте VDI маячит на 300+ десктопов, вот рассматриваю варианты. Или отдать его на откуп VMWare VSAN и не париться, или реализовать какой-то свой велосипед для повышения образованности :)

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

в zfs дедупликация тоже есть, но только онлайновая (насколько я помню)

Такая и нужна. А бтрфс - нее, не в продакшен.

к тому же zfs - это не для linux

По религиозным соображениям?

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

Когда-то дома на насе юзал - всё так и было, но там памяти ошеньма малама было, всего 8гб :) А тут, как видно, надо овер 128гб :)

Бэкенд у меня и так планируется на ссд делать, так что еще несколько штук поставить под l2arc, в принципе, не проблема. Надо обдумать.

А тут, как видно, надо овер 128гб :)

тут однозначно тестить надо.

Такая и нужна

ну тогда покупай тонны памяти

По религиозным соображениям?

по практическим: zfs не в ядре и не будет, а играться примотанными изолентой к ядру ФС себе дороже

по практическим: zfs не в ядре и не будет, а играться примотанными изолентой к ядру ФС себе дороже

Чем фс в ядре от не в ядре отличается практически? Ядра для своих хранилищ я и так собираю сам + модули всякие внешние (scst, drbd иногда). Так что модулем больше, модулем меньше - мне пофиг, главное чтобы работало стабильно.

ну тогда покупай тонны памяти

Кулпю, если это поможет. У меня есть свободный сервер с 256Гб памяти - попробую на нём погонять.

320 байт на блок в таблице дедупликации - куда им столько?

Hello, Constantin,
interesting discussion; the post refers to the ZFS FAQs for the way to assess the max amount of memory taken by the DDT entries. I think there is a bit of overestimation there:

looking at the code in illumos, for instance, one can see that there are two ways DDT consumes memory:

1) as blocks buffered in ARC
2) as ddt_entry_t in the avl_trees in ddt_t structs

the latter is transient as it is destroyed at every txg processing boundary (spa_sync() call), and the former is limited to 1/4 of ARC size by default, as mentioned in this post. If we were to let the ARC grow unlimited, the size taken in ARC would be:

'on-disk DDT entry size' times 'total number of entries'

The on-disk size is 64 bytes (echo "::sizeof ddt_phys_t" | sudo mdk -k"), which is significantly less than 320 bytes - the estimate used for calculations in this post and the ZFS FAQs. The ddt_phys_t can be compressed, so, in fact, the size of DDT entries on disk is 64 bytes or less.

I believe a better way to estimate DDT memory requirements is to use the size of the DDT entry on disk, as opposed to the size of in-core DDT entry ddt_entry_t (which appears to be 376 bytes at this time: echo "::sizeof ddt_entry_t" | sudo mdb -k). The reason for this is that DDT is cached as blocks in ARC, not as ddt_entry_t structs, as I understand it.
Best regards, Boris.

Интересный коммент, спасибо, значит дело может быть не настолько плохо :)

Чем фс в ядре от не в ядре отличается практически?

Приоритетом выполнения кода fs. В ядре быстро, в userspace медленно. Ну типа так считается.

Не, тут речь о том включено оно в ванильное ядро или нет. Так то оно всё ядерное, что зфс что все остальные.

Ты я так понимаю, активно гоняешь zol в продакшене?

Не, тока дома, но уже очень давно и без особых проблем. Вот думаю мож в продакшен ему пора :)

Чем фс в ядре от не в ядре отличается практически?

Свой кэш, отдельный от VFS?

См. выше, не про фьюз всякий речь. А про ФС, не включенные в ванильное ядро.

Я в курсе, но в ядрёном тоже самое.

да, одна из причин

другая причина - развитие её проходит ортогонально развитию ядра, что чревато потенциальными проблемами в будущем

впрочем, можно попользоваться и zfs, пока btrfs не допилят полностью

Фс мне вообще не нужна, я хочу экспортировать это дело по фиберченнелу или айскази

Оффтоп. Какое железо + ПО позволит экспортировать диск по fc ?

Оффтоп на оффтоп. Соляра и любая fc hba.

SPL(solaris porting layer) тоже не сахар походу.

Кто мешает в ядре налабать свой кеш? Разве что Линус не пустит тебя в ядро :)

SCST/LIO + Qlogic/Emulex/ещекакойнибудь FC HBA

Ну ты попробуй, потом расскажешь, как оно :)

Спасибо. Про LIO уже слышал, пора изучить :)

Why соляра?! :)

LIO не пробовал, юзаю SCST, всё хорошо. под 200к иопсов через 1 порт Qlogic 8Gb FC HBA проталкивает, упирается в сам HBA.

Because!!!
Потому что COMSTAR в ядре и интегрирован с остальной частью системы, как и всё остальное.

А зачем поверх zvol чужие fs,когда своя есть?

Ну не знаю, может человек хочет виртуалки держать на ZVOL-ах - вполне себе законное желание. Учитывая что дедупликация и снапшоты работать в такой системе должны. Насчёт сжатия - хз

Блочная дедупликация в Linux

Не смешите, они (Linux community) еще снапшуты не сделали :)

zfs

Linux

Вы ничего не путаете ?

А в чем проблема?

С LIO была запара с устройством, zvol использует 230 для устройств, а LIO их, без патчей, не раздает.

И? LIO тоже в ядре, в чем разница? При этом энтерпрайзные хранилки компании делают упорно на основе SCST, который не в ядре :)

Ну, еще камень в огород LIO. Продолжу его не юзать :) для SCST до фонаря что экспортировать.

На сколько я помню - zfs модуль для ядра это продукт сам в себе.

FUSE - ну только для чтения, и то в критических ситуациях.

Каждый дротит, как хотит, мне удобнее соляра :)

Да пжалста, просто тут линукс.орг.ру :)

zfs модуль для ядра это продукт сам в себе.

Ну, у меня этот продукт на 10Тб массиве работает уже пару-тройку лет без единого разрыва (ц)

Ну так с этими вашими линуксами тоже приходится ковыряться, надо быть в курсе событий :)

просто тут линукс.орг.ру :)

я захожу на opensource.ru :p

плюсую. полтора года работы 6-ти серверов с виртуализацией kvm on zfs(ZOL) без косяков.

Вы ничего не путаете ?

Нет, а вы?

Горячая итальянка Фиберченнела и экзотическая азиатка Айскази