Proxmox grub /boot

не правильно вы дядя Федор бутерброд мастрячите :)

Ну, ещё лежит sas10k под l2arc, и нормальный ssd под zil. так нормально будет?

а эти новые диски случаем не с 4к сектором?

Не помню вечером смогу посмотреть. Там вд ред, примерно 12-13 года, но без пробега. 512 вероятнее.

Да пофиг на физический размер сектора, ставь 4K на пул вне зависимости от размера сектора. Учитывая, что логический размер сектора даже с физическим 512 часто встречается 4K, то ну нафига?

L2ARC на обычном харде?? Ещё более неправильный бутерброд.

zil не даст профита виртуалкам если в них не БД будет крутиться.

По поводу 4к: вопрос задам по-другому с каким ashift будет создан пул, 12 ?

Ты что-то напутал. Есть диски 512n, 4kn и 512е (512лог/4кфиз). 4к/512 нету.

L2ARC на обычном харде?? Ещё более неправильный бутерброд.

sas10k обычный хард? L2ARC тут для уменьшения количества обращений к дискам. А какой бутерброд правильный?

zil не даст профита виртуалкам если в них не БД будет крутиться.

Есть мнение, что он даст профит в любом случае

По поводу 4к: вопрос задам по-другому с каким ashift будет создан пул, 12 ?

Гугл пишет по этим дискам и 4к и 512, как включу — узнаю. Если 4к, то ashift 12.

sas10k обычный хард?

На фоне SSD и 15-тысячники уже не смотрятся. Тут уже большую роль будет играть количество блинов в диске и плотность записи на них. Есть у меня на одном из серваков RAID5 из 5 15к сигейтов по 143Гб, и кроме как последовательным чтением похвастаться ему особо нечем. А в реальной работе он до хорошего SATA SSD всё таки не дотягивает.

zil

Есть мнение, что он даст профит в любом случае

Но сможешь ли ты его почувствовать? Профит-то будет далеко не при всех типах нагрузок.

zil не даст профита виртуалкам если в них не БД будет крутиться.

Есть мнение, что он даст профит в любом случае

Типичная нагрузка на пул:

zpool iostat 60
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool        821G   107G     45     75  1.02M  1.50M
rpool        821G   107G      2     79  19.0K  1.04M
rpool        821G   107G      8     89   231K  1.57M
rpool        821G   107G     17     92   141K  1.64M
rpool        821G   107G      2     81  18.1K  1.15M
rpool        821G   107G      1     93  14.4K  1.57M
rpool        821G   107G      1     79  8.53K  1.02M
rpool        821G   107G      1     80  15.4K  1.06M

А в реальной работе он до хорошего SATA SSD всё таки не дотягивает.

Так под l2arc же, иопсы там не нужны, объём 900 Гб. Для снятия нагрузки как-раз.

Но сможешь ли ты его почувствовать

Наверно нет.

Ты что-то напутал.

Да, наоборот. Я вчера так за..бался, что мог и не такого набредить.

sas10k обычный хард?

обычный, с чуть меньшим латенси и большей скоростью sequence io

L2ARC тут для уменьшения количества обращений к дискам

L2ARC by desing есть кэш на SSD(!) для random read, его можно попросить кэшить и sequence read, но это не даст профит если под ним пулл из более 1 диска.

Есть мнение, что он даст профит в любом случае

zil это не write cache, это sync_write_log, профит от него имеют те кто пишет в режиме sync_write, а это в основном СУБД. еще NFS этим страдает и iSCSI, но их можно переключить на async.

А какой бутерброд правильный?

вкусный =)

про L2ARC & ZIL я выше написал.

RAIDZ by desing предназначен для sequence io

и из-за особенностей хранения zfs/zvol records, на пуле с ashift=12 из 4-х дисков у zvol с дефолтным volblocksize=8k ты получишь оверхед в 50% против 33% у raid5, а можешь получить и все 100% как у mirror если они не пофиксили странную кратность выделения (N+1, где N - уровень raidz[1,2,3]) LBA под zfs/zvol records.

Так под l2arc же, иопсы там не нужны

нее, L2ARC как раз для iops и нужен, raidz на 4-х HDD выдает те же 500 МБайт/сек seq io. что обычные саташные SSD

l2arc же, объём 900 Гб

кстати.. метаданные L2ARC уменьшают полезный объем у ARC, 900 гигов это слишком

L2ARC by desing есть кэш на SSD(!) для random read

Для совсем random read его объем должен быть сравним с самим пулом, иначе читать с пула всё-равно прийдётся. А для часто запрашиваемых секторов пула есть arc. В связи с тем, что на l2arc вытесняются неиспользуемые данные из arc, вообще сомнительно попадание туда random read секторов, запрошеных с пула 1 раз.

RAIDZ by desing предназначен для sequence io

Так разве zil, в данном случае на отдельном устройстве не увеличивает sequence?

Если zil подключить к существующему пулу, по iostat можно будет посмотреть интенсивность его использования? Или так ничего не будет видно?

Для совсем random read его объем должен быть сравним с самим пулом

правильно, поэтому там где много-много iops надо пулл делают на SSD без L2ARC.

В связи с тем, что на l2arc вытесняются неиспользуемые данные из arc, вообще сомнительно попадание туда random read секторов, запрошеных с пула 1 раз.

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

Так разве zil, в данном случае на отдельном устройстве не увеличивает sequence?

1. нет, zil_on_ssd задизайнили для уменьшения sync_write_latency.

2. да =), но в том случае если ты делаешь seq_sync_write маленькими блоками например 4к.

Если zil подключить к существующему пулу, по iostat можно будет посмотреть интенсивность его использования?

конечно можно, zpool iostat -v pool 1

PS: я тебя от использования zil_on_ssd не отговариваю, но их надо 2 в зеркало, при его отказе есть риск получить нерабочий пулл с его последующим ремонтом, а это тот еще гемор..

zpool iostat -v

Подключил zil на тот пул, что есть.
Объём в 20 раз меньше, чем на каждый диск.
Но нагрузка на диски в 3 раза меньше, чем в рабочее время. Нагрузка в выходные не типичная.

Загрузка большого файла, через торрент на виртуалке:

              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool        821G   107G    475    153  7.35M  9.10M
  mirror     821G   107G    475    116  7.35M  5.01M
    sda2        -      -    475    116  7.35M  5.01M
    sdb2        -      -      0      0      0      0
logs            -      -      -      -      -      -
  sdc       53.1M   232G      0     37      0  4.09M
----------  -----  -----  -----  -----  -----  -----

Иии… на что тут смотреть?

zil_on_ssd задизайнили для уменьшения sync_write_latency.

но ведь не только, без отдельного zil у тебя sync запись всё равно сначала пишется в zil, только хранится он на дисках пула и страдает как запись, так и чтение.

Объём записи на zil не сильно отстаёт от объёма записи на пул.

так он и не должен отличаться, если это o_sync и ко, просто в разное время пишется.

так он и не должен отличаться

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

zil не даст профита виртуалкам если в них не БД будет крутиться.

В выходные нагрузку не создать близкую к реальной, вот и использовал торрент для теста. А так, может мне действительно zil на отдельном устройстве не нужен.

но ведь не только, без отдельного zil у тебя sync запись всё равно сначала пишется в zil, только хранится он на дисках пула и страдает как запись, так и чтение.

Именно для low-latency его и запилили. От ssd подтверждение операции приходит на пару порядков быстрее.

И… у тебя торрент стал писаться быстрее? :)

Потестил zil на реальной нагрузке:

              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool        821G   107G      5     22   119K   625K
  mirror     821G   107G      5     21   119K   605K
    sda2        -      -      5     21   119K   605K
    sdb2        -      -      0      0      0      0
logs            -      -      -      -      -      -
  sdc       1.45M   232G      0      0      0  20.9K
----------  -----  -----  -----  -----  -----  -----

cache=writeback

Йоу! т.о. у тебя IO кеширует и виртуалка и ARC и pagecache ?!

Не, ksm конечно сдедупит это все… но нафига?

но нафига?

Костыли.
Кривая, однопоточная софтина в вайне принимает кучу мелких пакетов, и пишет два десятка логов. От софтины требуется отзывчивость.
Вот и включил кеш на запись.(разницу в производительности не замерял)