Свежие комментарии

Я не могу остановить жизнь по всему дому и поставить чистый эксперимент. С другой стороны, "по всему дому" за время эксперимента - вряд-ли больше пары гигов записали, поэтому почти чистый получился.

На 1-м диске (по всем - не стал):
before = 101321660 kw/i
Пишем набор файлов (крупных) 56603105725 байт.
На каждый диск из шести должно лечь 9212745 килобайт "чистых данных" (предыдущее число делить на 6) (считая что в килобайте - 1024, не знаю как iostat считает)
after = 112879668
То есть легло: 11558008

Оверхед получается 1.254. Ожидаемый - 1.2 (6/5). Ну вот опять - единицы процентов оверхеда, с точностью то time machine на мак мини жены (ну не стал я проверять, работает оно там у нее или нет)

Если на пуле не было данных, то для чистоты эксперимента можно пересобрать пул на трёх зеркалах и подтвердить соотношение 3*V против 5*V :).

Очень хорошо, что под рукой есть raidz на 6 дисков. Если можно перед копированием дать iostat -Ix. Скопировать большой файл и опять дать iostat -Ix. Сравнить размер файла с тем, сколько реально записалось на диски. Если пул был пустой, то можно получить минимальный возможный оверхед при записи. Если на пуле были данные, была фрагментация, то более менее реальный.

Всегда же можно достать и померять. Вот копируем с винды на ZFS папку с большой виртуальной машиной (с единичной SSD, т.е. эти 450MB/s - это может быть вообще скорость источника):

Вот что говорит zpool iostat -v 10 (10 - чтобы как-то усреднил) примерно в момент скриншота:

                                           capacity     operations    bandwidth
pool                                    alloc   free   read  write   read  write
--------------------------------------  -----  -----  -----  -----  -----  -----
zdata                                   11,7T  10,0T      4    616  50,0K   451M
  raidz1                                11,7T  10,0T      4    616  50,0K   451M
    gptid/6d3f4070-3cdb-11e4-bb7d-001b21712630      -      -      0    509  9,20K  91,4M
    gptid/d6a2b2b5-3057-11e4-b611-001b21712630      -      -      0    505  5,20K  91,4M
    gptid/1e257ad1-2213-11e4-9cc0-001b21712630      -      -      0    502  8,00K  90,8M
    gptid/31eec4e7-a2d4-11e3-a262-001b21712630      -      -      1    503  10,8K  91,8M
    gptid/3321938d-a2d4-11e3-a262-001b21712630      -      -      0    505  4,80K  91,0M
    gptid/a189697b-1714-11e4-90ed-001b21712630      -      -      1    500  12,0K  90,6M
--------------------------------------  -----  -----  -----  -----  -----  -----
 

Что мы видим:

1) На пул пишется 451 данных, а винда показывает 446. Это либо точность измерения, либо тот оверхед, о котором вы говорите. Она (точность)/он(оверхед) в районе 1-2%

2) На диски пишется 6*91 = 546Mb/s данных + четности

3) Сколько мы ожидаем "данных плюс четности"?  451*6/5 = 541. Опять, то ли в пределах точности (я все цифры у дисков округлил до 91, на глазок, может и зря) то ли еще 1% оверхеда.

Ну вот 9*V минус несколько процентов оверхеда - будут сильно быстрее 5*V.

А еще лучше - 12, потому что делится на все.

Наверно я плохо понимаю, поэтому простой пример - пусть один zpool из двух mirror по два диска (всего 4 диска в пуле) и пул raidz такой же емкости из трёх дисков (как вариант можно рассмотреть ещё raidz2 из 4 дисков). Если сравнивать скорости чтения/записи (понятно нужно оговаривать характер нагрузки), то быстрее будет первый пул.
Я работаю с полиграфическими данными (небольшая компания), поэтому мне очень близка данная тема (Photoshop, Illustrator, InDesign, Acrobat, большие файлы, скорость передачи по сети).

Ну где "выигрыш в скорости записи то"?

Я еще раз повторяю, в N-way mirror мы пишем в N раз больше данных. В raidN на K дисках: в K/(K-N) раз.

Вывод: при фиксированном N (скажем, два) и фиксированном K (большем чем 2N) - raid будет быстрее на запись (но медленнее на чтение)

Проигрыш в объеме при использовании зеркал однозначен, зато выигрыш в скорости записи и при чтениии более, чем в один поток.

В зеркале два или более диска пишут одинаковую информацию параллельно, поэтому можно считать, что зеркало пишет со скоростью одного диска (правильнее со скоростью самого медленного). Можно для тестов вообще не делать зеркала. Я сравнивал пул одинакового размера.

raidz по записи будет медленее, чем такой же по объёму страйп из дисков/зеркал. Это вытекает из транзакционности записи в zfs и большому пенальти raidz при read-modify-write. Простым языком - количество записываемой информации на диски будет больше при raidz. Это достаточно легко проверить записав файл и проверив сколько реально было записано на все диски информации (понятно, что при заполнении пула этот эффект будет проявляться всё больше и больше). Для повышения скорости записи больших файлов можно отключить zil (на отказоустойчивость не влияет), изменить logbias, redundant_metadata, что также влечёт уменьшение количества записываемой информации. Добившись минимальных накладных расходов при записи оцениваем загрузку дисков gstat-ом. Если имеем 100% загрузку дисков при записи файла - система упирается в скорость дисков, если нет ищем во что упираемся.

Я думал, это синдром русскоязычных коммьюнити…

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

Ну это верное замечание, но
а) а может кто уже что-то такое мерял? Ну вот я же мерял 4 года назад

б) припираться в (новую для себя) рассылку/форум, задавать там вопрос (который, возможно, миллион раз обсуждали уже) - это большой шанс выставить себя идиотом. Ничего страшного в этом нет, ну идиот, бывает, проблема в том, что идиотам по существу не отвечают

по моим наблюдениям, запаса CPU у нас обычно есть даже везде включить lz4. А вот памяти много не бывает, и latency там, кажется, играют большую роль чем потоковая скорость.

Но -- надо ставить эксперименты.