VirtualBox disk - zvol из ZFS - оптимизация

https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/QdANOD9lZBM

volblocksize
zvol

смотря как организован пул. если в нем один диск или это единичное зеркало, то оптимально будет 128K, если это 10-рейд из 2-х зеркал, то 64K, а если из 4-х тогда 32K

т.е. оптимальный размер volblocksize=128K/кол_во_зеркал в пуле по типу RAID10?

получается размер по умолчанию = 8К рассчитан на 16 зеркал (всего от 32-х дисков и более в зависимости от кол-ва в каждом зеркале)? откуда эта инфа? есть тынц (URL)?

а как же:
1) насыщение канала большим кол-вом блоков при случайном чтении?
2) зависимость от соотношения больших файлов и малых внутри дочерней файловой системы, расположенной на ZVol и ее способности к дефрагментации?
3) наверно и еще многое другое?

ИМХО нужно снять статистику ввода вывода тома и выбирать размер блока с самым большим показателем по статистике...


например, если основной размер обмена 4К-блоки, а том создан с 64к-блоками, то при рандомном чтении на каждый 4к блок будет реально читаться 64к (оверхед по чтению)

если том создан с 4к-блоками, а основной размер обмена 64К-блоки - то 64к блок может быть фрагментирован в zfs и в худшем случае чтение каждого блока 64к превратится в чтение 16 блоков по 4к разбросанных по диску...

смотря как организован пул. если в нем один диск или это единичное зеркало, то оптимально будет 128K, если это 10-рейд из 2-х зеркал, то 64K, а если из 4-х тогда 32K

интересно, где ты такой ерунды начитался?

Присоединяюсь к вопросу.

кстати устраивал небольшое тестирование с NTFS блоками 4K на нескольких ZVol с блоками 4K, 8K, 16K, 128K
на ZVol 128K еще пробовал NTFS с другими размерами блоков

компик слабенький 5 летней давности

ZFS - NTFS write-read read operations/sec by zpool iostat

4-4 - 80 - 20 1-5K
8-8 - 80 - 30 0.5-3K
8-4 60 35 0.5-2К
16-16 20 - 40 0.5-2K сильно грузит проц
16-4 60 - 45 0.5-1.5К проц грузит обычно
128-64 75 - 120 0.5K
128-4 70 - 110 1K

похоже вендовый NTFS не любит блоки NTFS размером 16K в независимости от размера блока ZVol, проц жутко тормозит, мышка коекак ползает
в остальных режимах такого нет

тоже самое с табуляциями более лучше смотрится http://pastebin.com/raw.php?i=3GKKi3Jp

в результате пришел к варианту ZVol блока=128К, NTFS=4K, для случае БЕЗ iSCSI когда напрямую к контроллеру

на компе поновее 2 летней давности:

Crystal Mark в т.ч. random: http://picpaste.com/pics/LbAzhxs6.1439299219.jpg

это на одиночном HDD без ZIL и без L2ARC, только ARC и тот залочен на 512Мб

вендовой виртуалке было выделено 1гиг оперативы, чтобы не сильно кэшировала последовательные операции объем тестовых данных 4 гига

это на одиночном медленном ноутбучном HDD

да,да — мы в курсе тормозов ZFS, расслабься.

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

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

функциональность и есть цена производительности, поэтому тезис о тормозной zfs остаётся в силе — arc, zil, disk space reservation — попытки компенсации тормозов за счёт ресурсов — ростет стоимость системы.

функциональность - не цена, а профит,

ценой (- производной в том числе от функционала) могло бы быть падение производительности,

но при грамотно организованном пуле (L2ARC, ZIL на правильных enterprise SSD) происходит увеличение производительности

демагогия

демагогия

что значит демагогия?

я аналогично могу заявить, что квалификация моего комментария демагогией - есть демагогия,

можно ответить по существу вопроса?

например, какая файловая система может обеспечить для СУБД в процессе реорганизации базы производительность на уровне 50-100 тысяч IOPs, если массив в основном представлен дисками HDD с IOPS около 100 единиц на диск?

ZFS при этом будет работать на несколько порядков быстрее (в 100 раз)

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