Вот по дороге едет ZIL и я им буду....

Вот есть у меня стораджбокс, в нем 8x1Tb WD RE в RAID6 на Adaptec 5805.

Тогда, когда я его собрал, то есть 4 года назад, я сравнивал аппаратный RAID с RAIDZ2 (и zvol на нем) и аппаратный был значительно быстрее. Конкретные цифры в блоге не нашел, но если память не врет, то RAIDZ2 была процентов на 20-25 медленнее на записи больших файлов.

И вот сегодня, засунув в тот же ящик еще 6 дисков (3x1Tb ноутбучные 2.5" и три старых SSD-шки, которые я хочу на L2ARC) я наконец понял в чем дело (сделав отдельный ZIL на SSD и посмотрев на вывод zpool iostat -v):

  • Бутерброд zfs - zvol - ctld - iscsi - Windows8.1 создает БОЛЬШОЙ ТРАФИК на ZIL.
    Я не знаю, кто там делает fsync() или его аналоги, но в лог пишется МНОГО.
    Собственно, вот zpool iostat -v 60 в процессе копирования Far-ом больших файлов:

    Трафик в logs (они striped) примерно такой же, как трафик в raidz.
  • А бутерброд zfs - samba 4.3 - Windows 8.1 трафика на ZIL создает примерно ноль (и пишет данные сильно быстрее).

Понятно, что zfs set sync=disabled на нужный zvol - проблему частично решает. Но именно что частично:

  • Копирование большого набора данных на этот том происходит с сильно переменной скоростью. Просто вот видно как набирается кэш (14 гигов отдано ZFS) со скоростью источника (~450Mb/sec), а потом он начинает сбрасываться (и в это время данных почти не берет).
  • Самба работает плавнее и средняя скорость (я по 100 сек усреднял) получается где-то на 20% выше.

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

 

Comments

А какой смысл для работы, по описанному ранее патерну, вообще оставлять включённым zil?

Проблема наверно не в iscsi, а в zvol (точнее в самой организации блочного устройства на базе zfs).

Насколько я понимаю, если нет отдельного ZIL-девайса, то тот же лог, те же двойные данные по сути, пишутся на основной массив, в какую-то резервеированную область?

Так то я log device подключил - чтобы увидеть "ZIL-трафик". Увидел. Удивился.

Ну и проблема в том, естественно, что кто-то из Windows8.1 или ctld хочет писать синхронно (и непонятно где это включается-отключается)

Вдогонку.
У меня, собственно, и не было iscsi поверх zfs/zvol, RAID6-том был сделан средствами Adaptec и скорость доступа - "вменяемая" (до 700Mb/sec при линейной записи).

Сейчас возникла идея переехать на RAIDZ2+L2ARC - чтобы для активных данных использовать SSD-кэш.
И, похоже, что доступаться к этому надо не по iscsi как я привык, а по самбе.

Моё мнение, подключение по iscsi zvol или файла, лежащего на zfs - это добавление большого оверхеда с естественным снижением производительности. Для борьбы с этим снижением приходиться идти на всякие уловки и использование дополнительных ресурсов. Samba/nfs более естественный для zfs канал доступа.

Опять моё мнение, использование L2ARC для samba-сервера может оказаться стрельбой из пушек по воробьям. Здесь нужно определиться что кешировать и зачем.

Мне вот iscsi нравится. В частности тем, что это "монопольный доступ" - и соответственно клиент может активно кэшировать на своей стороне.

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

samba (точнее протокол smb) позволяет и кэширует на стороне windows-клиента. В этом легко убедиться. Исходя из этого сразу возникает вопрос зачем кэшировать данные на стороне samba-сервера?

Вопрос в объеме же и переживании перезагрузки.

У меня сейчас сеть - быстрее (HDD-)дисков, и по latency и по bandwidth.

Поэтому смысл в автоматически работающем SSD-кэше - просматривается, буду пробовать (понятно что их надо 3-4 штуки, чтобы 10G забить).
Не понравится - верну в рабочую станцию, буду на них "рабочие файлы" копировать.

>> There are three different caches utilized by the client SMB network redirector if SMB 2.0 is the negotiated protocol

Это кэши метаданных все же.
https://technet.microsoft.com/en-us/library/ff686200(v=ws.10).aspx

С кэшами данных же сложнее, вот паттерн же:
- клиент открыл файл, прочитал, закрыл
- некий софт на сервере (не пользуясь SMB) обновил файл

Откуда самбе знать, что этот файл надо мониторить на тему обновлений?
Либо мы при переоткрытии клиентом - должны сходить на сервер и что-то проверить (это latency, даже если сам файл не будем гонять). Либо не будем туда ходить - и клиентский кэш устареет.

Сходить проверить - сильно медленнее локальной RAM же.

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

В случае iscsi - монопольного доступа - никаких таких проблем нет, монопольный кэш на клиенте всегда актуален.

Для файлового samba/smb-сервера согласование кэшей и достоверность данных наверное самое главное :-). Мой опыт подсказывает, что он с этим справляется, можно сказать, хорошо. Припоминаю только, что нарывался на проблемы, если небольшой файл обновлялся по ftp (по моему встроенным в explorer ftp клиентом), а у windows клиента продолжал читаться закешированный файл и требовалось сделать небольшие манипуляции для обновления.

Я имел ввиду, что у каждого клиента есть своя оперативная память, клиент прочитал файл и его закэшировал. Также он закэшировался на сервере и получается двойное кэширование. Если клиент изменил файл, то смыл было кэшировать на сервере? Если закрыл и снова хочет открыть, то какая вероятность, что у клиента вымылся кэш, а у сервера он ещё остался в памяти? Особенно если клиент не один?

Вот и я о том же - мультиюзер требует сложного и затратного протокола для согласования кэшей.

А с iscsi этой проблемы вовсе нет.

И результат, заметим, на лице.

Один и тот же фолдер с ~5000 файлов, копии на iscsi и на SMB (на разных машинах), потому что iscsi подготовлен к разборке
- первое открытие (Far-om) - iscsi быстрее
- следующие открытия - iscsi СИЛЬНО быстрее, потому что по сети вообще никто не ходит.

За то и любим

Мне кажется немного не корректное сравнение :-). Диски-контроллер-iscsi-ntfs-каталог против диски-zfs-smb-каталог. Получается условно сравнение ntfs против zfs. Я тоже перезжал с iscsi на самбу и такой разницы не заметил. Мало того повторное открытие каталога на самбе, как по мне так мгновенно (правда каталог с 5000 файлами не нашёл). И ещё я сомневаюсь, что на самбе по сети при повторном открытии каталога кто-то сильно ходит. Хотя можно проверить :-).

Ходит, еще как ходит:

Первый всплеск - первый заход в каталог. Второй  - повторный заход.

root@home-gw:/home/lexa # netstat -I ix0 1
            input            ix0           output
   packets  errs idrops      bytes    packets  errs      bytes colls
         0     0     0          0          0     0          0     0
         0     0     0          0          0     0          0     0
         0     0     0          0          0     0          0     0
         0     0     0          0          0     0          0     0
         0     0     0          0          0     0          0     0
        75     0     0       7453        113     0     859617     0
        27     0     0       2556         39     0     289960     0
         0     0     0          0          0     0          0     0
        11     0     0       1958         11     0      16974     0
         0     0     0          0          0     0          0     0
         0     0     0          0          0     0          0     0
         0     0     0          0          0     0          0     0
        77     0     0       7202        117     0     924751     0
        22     0     0       2140         31     0     224012     0
         0     0     0          0          0     0          0     0


 

Только файлов не 5000, а 7349.
Это специальный тестовый каталог, да.

Дошли руки. Создал папку с 11111 реальными файлами. samba по гигабитному линку. Открываю папку на windows 7 стандартным Explorer вид отображения таблица (показывает имя, дату изменения, тип, размер). Первое открытие наверно до секунды (с zpool прочиталось около 2MB, по сети передалось до 1,5MB). Повторное открытие папки - доли секунды (с zpool прочиталось 4kB, по сети передалось до 1,5MB). Практически мгновенно появляется список файлов и затем происходит сортировка по имени (или как задано). Я бы не сказал, что это долго :-). Раньше вообще не обращал на это внимание и не возникало никакого дискомфорта.

Скопировал папку на локальный диск windows и стал переключаться между папками. Чуть медленнее. Разница максимум десятые доли секунды.

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

Случайно наткнулся на https://svnweb.freebsd.org/base?view=revision&revision=317064 и вспомнилось былое (еле нашёл :-)).

Хм, надо (попробовать) обновиться наверное. Потому что вот большие каталоги читаются не безумно быстро до сих пор.

Спасибо.

Но, вспоминая приключения со скоростью чтения - обновляться страшно. Может быть только вот этот патч накатить, например.

Ага, в 11.1 оно уже

Ну тогда ее и попробуем того, поставить.

Вот после апгрейда FreeBSD 11.0->11.1, metadata fetch (FRV) в большом каталоге (5000 файлов) стало кардинально быстрее (samba over 10G).

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

Я из-за 11.1 и полез смотреть, уж сильно руки зачесались :-). Но меня больше всего интересовало: https://svnweb.freebsd.org/base?view=revision&revision=307265. Кстати, тебя там тоже есть интересное: https://svnweb.freebsd.org/base?view=revision&revision=286570.

У меня большие блоки, на их фоне это все незаметно.

https://drive.google.com/file/d/0B5hUzsxe4cdmbEh2eEZDbjY3LXM/view
Меня больше интересует сжатие метаданных (под данные я в последнее время больше 1GB в ARC для samba-сервера не даю). Думаю если вдруг получится сжатие метаданных например раза в два, то надеюсь, что это будет как добавление допустим 50% RAM (жаль ещё минимум месяц не будет возможности проверить :-)). Там, кстати где-то мелькало и про влияние на большие каталоги.

Кстати, автор сжатия в арке и той "твоей проблемы" - одно лицо :-))).

Вот думаю тогда стоит подождать годик, пусть сначала на кошках

Так ты же уже обновился :-).

Плохо дело.

Сжатие включать не буду.

Мне кстати вот кажется, что
tar cf /dev/null bigfolder1
tar cf /dev/null bigfolder2
И так по кругу

Стали работать предсказуемее, чем раньше. Нет впечатления, что что-то выкидывают из кэша вникуда (место записи в L2)

Клиентов то может быть больше одного :)

Ну да.

Но если он один - то у SMB для этого нету флажочков.

Есть другие. Opportunistic locks были придуманы для обеспечения когерентности клиентских кешей. Другое дело, что там получается адово сочетание режима открытия файла приложением и реализации на стороне клиентской ОС и сервера. Но отключение oplocks, которые, кажется, включены по умолчанию, может ситуацию изменить в сторону большей эксклюзивности клиента, так сказать.

Хотя, скорее всего, основным эффектом станет увеличение размера серверного кеша :)

Правильно понимаешь :-). Ещё нужно чётко понять зачем вообще нужен zil.

Писать синхронно - это послать команду на запись и дождать её завершения не выполняя никаких других команд. Так как все современные диски с включённой отложенной записью (навряд ли кто-то явно выключает writeback, да и не нужно это, почти все давно уже научились использовать команду flush :-)). Поэтому правильнее сказать, кто посылает команду команду flush. Так вот zfs всегда при выполнении транзакции, по моим наблюдениям, использует две команды flush, независимо писались данные по iscsi или по sambe или ещё по чему-то. С другой стороны, если допустим, есть подключение windows по iscsi (ctld), то файловая система ntfs сама посылает команды flush на блочное устройство и уже подключенное ctld низлежащее блочное устройство (сырые диски, geom, zvol...) принимает решение как интерпретировать данную команду. С samba и nfs всё аналогично. Поэтому это не проблема, а естественное поведение при работе с блочными устройствами с отложенной записью. Что и как оптимизировать зависит от задачи.

Меня вот другое огорчает же - что по iscsi получается вся запись - синхронная.

Кто ее такой сделал, ctld или windows - я не знаю (и не знаю как разбираться "кто виноват"). Но результат таков, что "работает чудовищно" - потому что так работает ZFS с синхронной записью.

Отключить вообще синхронную запись в сочетании с большим кэшом на стороне ZFS-box - это тоже, нарываться на неприятности.

iscsi просто транслирует по сети команды для блочного устройства. Поэтому это подключение ничем не отличается от подключения локального диска (условно добавляется только задержка передачи по сети). "Синхронность" записи определяет инициатор (windows), поэтому iscsi здесь не причём. По iscsi можно утилизировать всю пропускную способность сети. Протокол довольно низкозатратный. Сам использовал около года. По MPIO на двух гибабитных линках выдавал больше 200MB/s в обе стороны.

Что значит нарываться на неприятности?

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

в общем, явно какая-то херня имеет место быть. Потому что наоборот - люди включают sync=always для каких-то своих целей, а иначе 'zero ZIL traffic'.

В zfs довольно затратная транзакция (правильнее группа транзакций). Нужно записать все блоки с данными и довольно объёмные метаданные (все указатели на записанные блоки, причём в зависимости от настроек их количество может быть отлично от 1, а на некоторые указатели всегда пишутся по 3 раза, все вышестоящие блоки в дереве должны быть обновлены/перезаписаны вплоть до uber-блока, который венчает завершение транзакции и должен быть записан 4 раза плюс может понадобиться перебалансировка всего дерева). Поэтому, как следствие для zfs предпочтительнее иметь большой recordsize и как можно больший объём записываемых данных в одной транзакции . Это входит в противоречие с потребителями данных (базы данных, клиент nfs, ...), которые часто хотят синхронизировать/записывать изменённые данные на диск и быть уверенным, что данные действительно находятся на диске. Получается можно нарваться на большую задержку :-). Для решения этой проблемы и придумали zil. Помоему сначала его и не было. Это компромиссное решение предназначено для обеспечения низкой задержки/латентности при частой синхронизации данных на диск, но оно увеличивает объём записываемых данных на диск :-(. На надёжность zfs zil никак не влияет. Он только обеспечивает, что данные пропадут не за последние 30 секунд (по-моему такая установка по умолчанию), а за меньшее время. Вот и весь выбор и соответственно выбор настроек:-).

Вот все это хорошо, пока мы говорим про файловую систему.

Но когда у нас в ней живет zvol, а в нем своя FS - проблема гарантий встает в полный рост, ибо не все данные одинаково полезны.

Гарантий чего? Если файловая система послала flush на zvol, то zfs по семантике начнёт транзакцию и максимум, на что нарвётся внешняя файловая система - это на увеличенную задержку при получении ответа о завершении flush. Кстати не все файловые системы умеют работать с блочными устройствами с отложенной записью. Например ufs (gjournal не считается) не умеет, поэтому синхронный режим монтирования на блочном устройстве с отложенной записью это фикция :-).

Ну я вот о чем
- метадату надо (констистентно) писать с sync
- а данные - как приложение велело

Вот бутерброде zvol-iscsi-ntfs получается какая-то непонятная ерунда, там чуть не все идет с sync (иначе отчего такой трафик на zil?)

Немного непонятно, что вкладывается в понятие "- метадату надо (констистентно) писать с sync
- а данные - как приложение велело".
Условно по iscsi на zvol или любое другое блочное устройство на исполнение передаются четыре команды (в терминологии FreeBSD) READ, WRITE, FLUSH, DELETE. Если посмотреть на статистику, то ntfs не злоупотребляет командой FLUSH :-). Проблема в zvol и его настройке. Если с помощью geom-ов на тех же дисках организовать блочное устройство и отдать его по iscsi, то с производительностью резко повеселеет :-).

Ну вот если "не злоупотребляет" - то откуда трафик на ZIL примерно равный трафику на массив?

Его не должно бы быть. Но он - есть.

А кто говорил, что трафика не должно быть? По моему в предыдущий раз я как раз настаивал, что он (оверхед) должен быть :-). Нужно разбираться в конкретном случае. Какие настройки recordsize, logbias, sync, redundant_metadata? По памяти не помню, но проверить что у нас там есть по sysctl на эту тему. Желательно знать какой размер блока у ntfs на данном томе?

Двойной оверхед?

Я не спец в этом вопросе, но даже я знаю, что чем меньше манипуляций с данными, тем меньше скорость чтения/записи.
Самба всегда была медленнее ИСКАЗИ.
ИМХО дело в организации массива и включенных "сервисных возможностях" ФС.
Уверен, FAT и EXT2 будут быстрее ZFS.
Также уверен, что RAID10 будет быстрее любого Z-RAID массива при одинаковом количестве дисков. Именно RAID10 юзают в ЦОДах Гугла.

"Категорически не рекомендую связку аппаратный RAID+ZFS - спор вряд ли возникнет." (c) Андрей Космос

Спецы есть и в теме "NAS своими руками"
http://forum.ixbt.com/topic.cgi?id=109:82

>> Самба всегда была медленнее ИСКАЗИ.

4-я самба и SMB3 - кисть дают!

Покуда multi-channel не начинает данные корраптить :)

IMHO smb 3.0 между парой windows машин вполне забивает пару гигабитных линков, ноздря в ноздрю с ISCSI

У меня 10G и сеть - быстрее дисков.

>> Уверен, FAT и EXT2 будут быстрее ZFS.

Теплое с мягким? FAT/EXT2 работают с одним блочным устройством, ZFS - с большим количеством блочных устройств (да еще и для разного предназначенных).

>> Спецы есть и в теме "NAS своими руками"

Ну есть. Например, я. http://forum.ixbt.com/topic.cgi?id=109:256-12

Речь шла о людях, которые уже знают ответы на вопросы других спецов.
Например MikeMac, который 2гуся.
Его блог:
http://2gusia.livejournal.com/7545.html

И ещё пяток товарищей...

Персоналочные б/ушные SSD СОЗНАТЕЛЬНО юзать под кэш, это даже не знаю как назвать...

Упоминая ФАТ, я имел ввиду минимум возможностей в обмен на скорость записи.

И среди очень умных людей встречаются желающие и рыбку и на ёлочку и ...
Вгрин на фотофоруме "хотел" качество СФ-задников в смартфонах, например. :-)
Вы ведь хотите "максимально надёжно И максимально быстро", "И при этом из дерьма и палок".
Я в таких случаях расставляю приоритеты и стараюсь не экономить.

Ну а что делать с б/у SSD? Сразу выкинуть?

Потеря кэша не страшна же ZFS (ну кроме скорости), а вот будет ли толк в смысле скорости - вот и посмотрим. Если будет - не жалко и серверных купить потом, по мере выхода из строя.

А зачем тогда аккумуляторы к RAID-контроллерам прикручивают? ;-)