LINUX.ORG.RU
ФорумAdmin

Дедупликация SDFS, или аналоги

 ,


0

1

Очень интересует тема дедупликации данных. Пока что остановился на SDFS: http://opendedup.org/

Возник вопроc: как расположить данные в определенной локации? Допустим у меня есть /mnt/sdb и /mnt/sdc, но при выполнении:

# mkfs.sdfs /dev/sdb --volume-name=volume1 --volume-capacity=1000GB
# mkdir /mnt/data1
# mount.sdfs volume1 /mnt/data1/

данные все равно располагаются где-то в корневой ФС (хотелось бы знать, где?).

Собственно, как быть дальше? Кстати, какие есть еще альтернативы помимо quadstor? Плюсы/минусы?


На FreeBSD есть виртуальная файловая система Nullfs. Используется с незапамятных времён для организации множества изолированных окружений (jail's) из одного образа с каталогами рабочего ПО. Если каждому окружению раздать права на запись, то со временем они «обрастают» специфическими (собственными) изменениями, «затеняющими» исходный образ в той мере, какие файлы изменены. В общем, технология похожа на дедупликацию на уровне файлов, а не блоков ФС (как это сделано в ZFS), что более экономически целесообразно и эффективно по затратам ресурсов CPU и RAM, я считаю.

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

При чём тут дедупликация? В ZFS и Btrfs тот же результат будет просто за счёт CoW. Что, собственно, и используется в LXD, который создёт новый контейнер как клон образа.

anonymous ()
Ответ на: комментарий от iZEN

Я так понимаю, с ZFS есть некоторые проблемы в Linux?

Просто в идеале, для начала, хотелось бы получить дедуплицированный local storage с рассчетом на виртуализацию. Но, опять же, никакой Proxmox я на FreeBSD не поставлю, да и с виртуализацией во FreeBSD, не сколько мне известно, тоже масса подводных камней.

Да и в целом, хотелось бы относительно универсальное решение для дедуплиакации данных вместо стопяцот возможных вариантов и дистрибутивов. Пробовал так же quastor: http://www.quadstor.com/ Но он не сканирует всевозможные виртуальные устройства (vdb он не видит точно), таким образом использование его в гостевых системах местами проблематично.

zuxla ()
Ответ на: комментарий от anonymous

Тему контейнеров и linked clones пока можно оставить. Пожалуй, в первую очередь интересует блочная дедупликация средствами файловой системы.

PS: Пока что подсказали, что я в спешке не создал путь перед созданием SDFS: https://serverfault.com/questions/851597/sdfs-filesystem-automount-on-start-up )) Попробую отпишусь - вдруг кому пригодится.

zuxla ()

Когда-то тоже хотел обзавестись хранилкой с дедупликацией. Почитал всяких форумов, статей и понял что этого мне не нужно : жор памяти, глюки, возможность просрать всё.

Deleted ()
Ответ на: комментарий от anonymous

Занятно, хотя и тонны мануала, конечно, вогнали в ступор :) Я так понял на вскидку оно только имеет смысл для FreeBSD? Готовые ISO не подойдут ввиду некоторых нюансов.

Про ZFS я смотрю пишут, что требования к оперативной памяти просто адовые, тогда как, например Quadstor, требует 2Гб (и 4Гб для всяких NAS) на каждый 1Тб дискогового пространства и при этом обещают подхватывать все метаданные с агрегированных дисков при переустановке/апгрейде.

zuxla ()
Ответ на: комментарий от anonymous

При включенной дедупликации на ZFS скорость чтения/записи на носители снижается примерно в десять раз. Жор памяти увеличивается тоже существенно. Это что б ты представил накладные расходы. На Nullfs таких проблем не наблюдается.

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

Теперь попробуй прочитать ещё раз. CoW без всякой дедупликации даёт то же, что твой костыль, но лучше.

anonymous ()
Ответ на: комментарий от anonymous

CoW без всякой дедупликации даёт то же, что твой костыль, но лучше.

Ну-ну. Основная цель «костыля» — примонтирование в ro и получаемый жирный (ибо nullfs прост как валенок https://github.com/freebsd/freebsd/tree/master/sys/fs/nullfs да еще и за 20 с лишним лет вылизан как кохонес домашнего кота в полном расцвете сил) плюс в виде дополнительного слоя защиты с минимальными накладными расходами. Дедупликация тут идет как побочный эффект.

anonymous ()
Ответ на: комментарий от iZEN

Если в кратции, то вот как хранит данные SDFS:

https://groups.google.com/forum/#!topic/dedupfilesystem-sdfs-user-discuss/b9O...

1. File metadata - this is the data that tell sdfs about hashes within individual files. This data usually represents about 1/100th of the logical data being stored. It should be stored on resonable speed disk 2. Unique File Chunks - This is the actual unique data being stored. This data size is directly related to the physical amount of data stored on disk. It should be stored on a resonably fast disk but can be stored on on whatever is the store and retreival speed you need. IO access is somewhat random so RAID is good. 3. Hash DB - This is the hash database that store the lookup table for if and where Unique file chunks exist in the system. It represents about 1/40th the size of the dse maximum size. It should be stored on fast disk such as SSD since most of the IO and bottleneck will happen in this area. SDFS will attempt to store the entire hashdb into memory but if it cannot, will read from disk. IO is random to this file.

--base-path - Determines the base location where all the data will be setup unless otherwise specificed by either --chunk-store-hashdb-location or --chunk-store-data-location. If you do specify the chunkstore locations only the file meta data will be stored in that location. --chunk-store-hashdb-location determines the hash db location --chunk-store-data-location determines the Unique file chunks location

Я усердно заморочался perfomance'ом, раскидав данные по носителям :) и теперь возникает резонный вопрос: может под хранение чанков использовать:

mkfs.ext4 -F -b 4096 /dev/sdb

или вовсе 512? Плюсы/минусы? Чанки там мелкие от 4к до 8к размером. Вроде при величине блока в 512 могла бы быть экономия объема, НО: будут ли тормаза?

И, да, имеет ли смысл вообще хранить это дело на btrfs? Вроде хвалят, что шустрее для мелких файлов, чем ext4.

PS: На заметку: ZFS против opendedup: https://groups.google.com/forum/#!searchin/dedupfilesystem-sdfs-user-discuss/...|sort:relevance/dedupfilesystem-sdfs-user-discuss/RBtcVpf5leY/4VIzu6rEAAAJ

zuxla ()
Ответ на: комментарий от dyasny

Кстати, не подскажешь, каким драйвером на сегодняшний день можно нормально пробросить HDD (чтобы было управление питанием, SMART из гостя), и требуется ли хорошо работающее VT-d?

anonymous ()
Ответ на: комментарий от anonymous

пробросить диск можно только через стандартные драйверы. Если нужно больше, то надо пробрасывать контроллер через pci-passthrough, и там таки нужен vt-d

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

пробросить диск можно только через стандартные драйверы.

Не совсем понял. Вопрос именно какой из них сейчас работает? Обрывочно гуглится про device=lun и bus=virtio, но у меня в данный момент нету libvirt, да и с тех пор, похоже, что-то поменялось не в лучшую сторону. Я экспериментировал с virtio-blk-pci и scsi-block, но обычно даже IDENTIFY не работало из виртуалки.

пробрасывать контроллер через pci-passthrough

Про это знаю, но в домашнем ынтерпрайзе нет не только контроллера, но и платформы, на которой такой проброс не будет иметь грустных последствий :)

anonymous ()
Ответ на: комментарий от anonymous

Не совсем понял. Вопрос именно какой из них сейчас работает? Обрывочно гуглится про device=lun и bus=virtio, но у меня в данный момент нету libvirt, да и с тех пор, похоже, что-то поменялось не в лучшую сторону. Я экспериментировал с virtio-blk-pci и scsi-block, но обычно даже IDENTIFY не работало из виртуалки.

диск (/LUN/LV/другое блочное ус-во) можно примонтировать в VM целиком, но надо указать понятный qemu драйвер. virtio-scsi, насколько я знаю, не выполняет протокол scsi целиком, virtio_blk вообще максимально упрощен. Так что остается или принят все как есть, или пробрасывать контроллер, или цепляться по iSCSI через сеть

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

Окей, понятно. Просто очень мало внятной информации: у многих virtio-scsi (насколько я понял, потому что писали про дефолт Proxmox) до определённого момента обеспечивал нормальный проброс протокола, но потом в QEMU начались изменения по части scsi=on, и теперь оно уже никак не работает. В любом случае я буду знакомиться с libvirt, так что попробую хаутушки с redhat.com.

anonymous ()
Ответ на: комментарий от zuxla

Иопсы не мерил, но документация, которую кто-то не читал, рекомендует использовать этот вариант как лучший по производительности, насколько я помню. У меня-то в основном контейнеры.

anonymous ()
Ответ на: комментарий от anonymous

Так... а я почему-то думал, что raw диски с выставленным VirtIO как раз так и быстрей...

Не затруднит ссылку на этот мануал? На вскидку ничего не могу найти.

zuxla ()
Ответ на: комментарий от zuxla

Кнопка Help в веб-интерфейсе. Там всё есть.

anonymous ()
Ответ на: комментарий от anonymous

вообще-то virtio_blk работает быстрее чем virtio-scsi, там намного более простой протокол, на один контроллер вешается не более одного диска, и еще кучка разного. https://mpolednik.github.io/2017/01/23/virtio-blk-vs-virtio-scsi/

scsi более логично использовать как дефолтный диск, но точно не потому что на нем производительность лучше.

dyasny ★★★★★ ()
Ответ на: комментарий от anonymous

Так я и писал про:

Add: Hard disk Bus/Device: VirtIO Format: raw disk image

и сам контроллер VirtIO SCSI, который и так по дефолту создается, при создании подобных дисков.

Разве это не то, что с максимальной производительностью?

zuxla ()
Ответ на: комментарий от zuxla

Чтобы было virtio-blk, нужно использовать контроллер Virtio. Давно бы уже сам проверил экспериментально и с помощью qm showcmd.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.