ZFS

Про ZFS и L2ARC

lexa — Fri, 04 Oct 2019 06:54:56 +0000

10G и Infiniband

У одного моего друга есть NAS на (7+2)-6Tb. Семь дисков в RAIDZ2 (том под данные), два диска в зеркале (том под бэкапы). И был там L2ARC-кэш на полтерабайта, Patriot Hellfire. Поскольку полтерабайта это мало (см ниже), этот кэш обслуживал только активные данные для работы, но не том с бэкапами, а для тома на котором живут торренты было secondarycache=metadata. И, в общем, было видно, что полтерабайта - мало.

Посмотрел один мой друг в прайслисты, посмотрел в обзор терабайтных SSD...

ZFS: vfs.zfs.compressed_arc_enabled=0

lexa — Fri, 10 May 2019 06:46:44 +0000

10G и Infiniband

У одного моего друга есть файловый сервер под FreeBSD 12 :)

И вдруг я он заметил, что скорость верификации бэкапов упала с 2-2.5 Gbit/s (это ограничение Acronis Backup, быстрее оно не делает) до меньше чем одного гигабита, 600-800Mbit/sec.

Ну вот vfs.zfs.compressed_arc_enabled=0 вроде как помогло. Процессор то медленный у ~~меня~~ него.

Продолжаем наблюдения.

Про Самбу 4.6

lexa — Tue, 06 Jun 2017 10:51:18 +0000

10G и Infiniband

У одного моего друга есть файлсервер с самбой. Прочитал я он CVE-2017-7494, пригорюнился и сделал pkg install samba46 (была 4.3).

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

Запатчил 4.3 патчем от 4.4-4.6 (благо там 4 строчки и место это не менялось) - и стало обратно хорошо, скорость на интерфейсе при бэкапе/верификации 2-2.5 гигабита (упирается дальше в диски), а с 4.6 было 1+. Конфиг, понятно, один и тот же.

Вполне возможно, конечно, что если потюнить, ну там удалить из smb4.conf те настройки производительности, которые для 4.3 были сделаны, а поставить какие-то другие, то станет обратно хорошо. Но времени и сил на это жалко.

Эх!

lexa — Mon, 10 Apr 2017 10:45:20 +0000

10G и Infiniband

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

Нет, ничего не сломалось, просто я понял что

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

Ну и купил гелиевый, а обычный - на полку.

Про ZFS L2ARC

lexa — Wed, 22 Feb 2017 18:45:29 +0000

В хорошую погоду zpool iostat -v zdata 5 выглядит теперь так

Но на самом деле, все как-то хуже. Не сильно, но все-таки.

Вот тут случился accidental reboot и я на пустом кэше попробовал так

tar cf /dev/null some-75Gb-folder

Ну и смотрю на скорости (на самом деле там tar cf - .. | mbuffer -s 16k -o /dev/null чтобы скорости видеть):

Первый проход: ~650MB/sec

ZFS primarycache=metadata и recordsize

lexa — Sat, 28 Jan 2017 10:06:31 +0000

Разное

Значит продолжение вот этой истории (в стиле "что вижу - то пою"): Про zfs primarycache (самая мякотка там в комментариях):

Поставил бэкапному dataset recordsize=64k (что соответствует типичному запросу на чтение самбой)
Подождал несколько дней, новые бэкапы создались с таким размером записи
Поставил primarycache=metadata
Запустил проверку одного из новых бэкапов:
- Скорость чтения снизилась до 100-150Mb/sec (было, с мегабайтной записью и primarycache=all 150-200)
- Скорость чтения с дисков соответствует скорости отдачи в сеть, "зря" ничего не

Про zfs primarycache

lexa — Mon, 23 Jan 2017 08:31:14 +0000

У одного моего друга есть FreeBSD бокс, на нем ZFS, Samba и 10G-ethernet. К этому боксу подключена рабочая станция с Acronis Workstation, которая туда делает бэкапы.

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

zfs set primarycache=metadata zbackup

Получилась такая фигня: если у Acronis-а запустить проверку бэкапа, то:

1. C ZFS-тома читается ~150-200 мегабайт/сек:
$ zpool iostat zbackup 1
...
zbackup 2,36T 2,17T 195 0 195M 0
...

Заканчивая неделю ZFS

lexa — Tue, 13 Dec 2016 17:26:07 +0000

Разное

Заканчивая неделю (или полуторамесячник) ZFS, финальные тесты. Списал данные, добавил еще один диск, прежде чем возвращать данные - маленько потестировал

Оборудование: i3-6300T, 32GB RAM, 7 дисков (6Tb HGST: 4 штуки 7k6000 и 3 штуки He8), диски подключены к чипсетному контроллеру (Intel C236).

Окружение: FreeBSD 11.0-p4

Методика: собираем пул, делаем на нем один датасет с размером блока 1m или 128к, пишем 200-гигабайтный файл
dd if=/dev/zero of=/zdata/testset bs=1m count=200k
Затем читаем этот файл той же командой dd в /dev/nul с...

(надеюсь) в последний раз про ZFS

lexa — Sat, 10 Dec 2016 16:46:19 +0000

Разное

Перебросил один (самый большой) датасет туда-сюда, старый пока не стирал.

И вот сравнение ("чтение реального микса файлов"):

Было (правда я через 20+ минут задолбался ждать и нажал Ctrl-C, за это время оно прочитало 200Gb):

$ tar cf - datasetname | dd of=/dev/null
^C418664864+0 records in
418664864+0 records out
214356410368 bytes transferred in 1414.744341 secs (151516005 bytes/sec)

Стало (аналогично, прервал прочитав 200Gb):

$ tar cf - /archive2/datasetname | dd of=/dev/null
^C421087495+0 records in
421087494+0 records out
215596796928...

Slow ZFS read: проблема не в коде а в данных на диске

lexa — Tue, 06 Dec 2016 16:37:00 +0000

Разное

Картинка, вероятно, уже надоела, но вот вам очередная порция тестов.

Ящик: Intel i5-2400, 16Gb RAM, Adaptec 5805, 5x4Tb (HGST NAS) в JBOD, собраны в RAIDZ2.

Свободного места достаточно:

$ zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zdata 18,1T 5,11T 13,0T - 9% 28% 1.00x ONLINE -

настройки в loader.conf:

vm.kmem_size="15G"
vfs.zfs.arc_max="14G"

Загружаем FreeBSD 11.0-RELENG:...

FreeBSD ZFS read: 11-STABLE тоже поломана

lexa — Tue, 06 Dec 2016 10:37:38 +0000

Разное

Все оказалось еще гораздо хуже, чем казалось на первый взгляд:

FreeBSD 11-STABLE тоже поломана
И поломка - это свойство, возникающее при записи файла.

Давайте значит по порядку.

I. Другой ящик:

i3-6300T, 32Gb RAM, 6 дисков по 6Tb в RAIDZ2, диски подключены к контроллеру на материнке.

II. Берем FreeBSD 11-STABLE, конкретно вот эту вот:

FreeBSD home-gw.lexa.ru 11.0-STABLE...

FreeBSD ZFS read speed: они убили кенни!

lexa — Tue, 06 Dec 2016 07:11:29 +0000

Разное

Вчерашний вечер у меня тоже прошел не скучно.

Я взял уже знакомый вам стенд:

i5-2400, 16GB RAM
LSI 9211-8i (FW 16.0, IT-mode, без BIOS)
7 дисков WD1003FBYX

И начал делать так:

Скачиваю с ftp.freebsd.org FreeBSD-NN.y-RELEASE-amd64-memstick.img
Пишу его на флешку
Загружаюсь с этой флешки (никаких дополнительных настроек!)
Собственно тестирую:

zpool create -O recordsize=nn ztest raidz2 /dev/gpt/DISK[0-5/6]
...

Про ZFS prefetch (2)

lexa — Mon, 05 Dec 2016 08:30:17 +0000

Разное

Продолжение вот этого вот текста, теперь более систематически.

АХТУНГ. Все описанные ниже эксперименты (и прошлая серия экспериментов) - относятся ТОЛЬКО к FreeBSD-12. На 10.3-11.0 (РЕЛИЗНЫХ, в -stable все похоже хуже) картина принципиально другая и деградации скорости чтения при маленькой глубине префетча нет.

Провел вчерашнее утро, а затем - вечер за стендом, который схематически показан на картинке (там 7 дисков, потом...

Про ZFS prefetch

lexa — Mon, 14 Nov 2016 08:24:41 +0000

10G и Infiniband

Вынесу из комментариев, потому что это важное, чтобы потом самому было легче найти.

АХТУНГ. Все описанные ниже эксперименты (и прошлая серия экспериментов) - относятся ТОЛЬКО к FreeBSD-12. На 10.3-11.0 (релизных! со -stable все сложно) картина принципиально другая и деградации скорости чтения при маленькой глубине префетча нет.

Собрал я тут ZFS массив на следующие (я надеюсь) лет пять: 6x6Tb, в RAIDZ2 (2 - потому что я устал срочно бегать в магазин, покупать замену вылетевшему диску), диски HGST, правда разные...

Про ZFS и манипулирование данными

lexa — Sun, 06 Nov 2016 16:23:14 +0000

Разное

Таскал тут данные туда-сюда, RAIDZ1 разобрать, RAIDZ2 собрать.

Но так как дисков/питания на "поднять оба массива сразу" не хватало, делал это хитровывернутым образом - скопировал на одиночные диски, потом собрал degraded-массив без этих дисков (подстановкой файликов из нулей вместо них), скопировал обратно, восстановил четность.

И смотрю я теперь на iostat -x 100 и не радуюсь:

device     r/s   w/s    kr/s    kw/s qlen svc_t %b
da0      330.3 10.1 11156.0   104.6    0   3.9 20
da1      330.2 10.4 11152.1   107.8   ...