jenci
как и проводов питания в наших краях за 182 руб найден BitFenix Molex to 4 x SATA.

MikeMac
в наших краях за 182 руб найден BitFenix Molex to 4 x SATA.
да, я первым делом пошел смотреть в ваш блог но потом вспомнил что у меня на БП молекса нет... нашел у себя в инетмагазинах "раздвоители" сата питания наверное куплю парочку когда попробую мой контроллер а-331 на совместимость и стабильность. а так теперишние все порты забиты дисками и к ним провода питания укомплектованы. нехватка только при экстренной ситуации.

RU_Taurus
Переставил систему. Backup 1tb происходил при средней скорости 50Mb/s. Пересоздал zfs pool:

nas4free: ~ # zpool status
  pool: data
 state: ONLINE
  scan: none requested
config:
 
        NAME                     STATE     READ WRITE CKSUM
        data                     ONLINE       0     0     0
          raidz1-0               ONLINE       0     0     0
            gpt/WD-WMC1T1576554  ONLINE       0     0     0
            gpt/WD-WCAZAF850805  ONLINE       0     0     0
 
errors: No known data errors

dd дал результат 93-95 мб/с (не помню точно). Восстановил с бэкапа. Скорость также была 50мб/с. решил сделать dd и выложить сюда:

nas4free: ~ # dd if=/dev/zero of=/mnt/data/Data/file.tst bs=1m count=5000
5000+0 records in
5000+0 records out
5242880000 bytes transferred in 71.539939 secs (73286056 bytes/sec)

Делал 3 раза, результаты каждый раз разные: 70......, 77...... bytes/sec
При этом dd на ufs диске в этой системе:

nas4free: ~ # dd if=/dev/zero of=/mnt/system/file.tst bs=1m count=5000
5000+0 records in
5000+0 records out
5242880000 bytes transferred in 56.957488 secs (92049004 bytes/sec)

iperf:

nas4free: ~ # iperf -c 192.168.1.35 -P 1 -i 1 -p 5001 -f M -t 10 -w 64K
------------------------------------------------------------
Client connecting to 192.168.1.35, TCP port 5001
TCP window size: 0.06 MByte (WARNING: requested 0.06 MByte)
------------------------------------------------------------
[  3] local 192.168.1.34 port 61822 connected with 192.168.1.35 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  53.9 MBytes  53.9 MBytes/sec
[  3]  1.0- 2.0 sec   103 MBytes   103 MBytes/sec
[  3]  2.0- 3.0 sec   102 MBytes   102 MBytes/sec
[  3]  3.0- 4.0 sec   102 MBytes   102 MBytes/sec
[  3]  4.0- 5.0 sec   101 MBytes   101 MBytes/sec
[  3]  5.0- 6.0 sec   102 MBytes   102 MBytes/sec
[  3]  6.0- 7.0 sec   102 MBytes   102 MBytes/sec
[  3]  7.0- 8.0 sec   102 MBytes   102 MBytes/sec
[  3]  8.0- 9.0 sec   101 MBytes   101 MBytes/sec
[  3]  9.0-10.0 sec   101 MBytes   101 MBytes/sec
[  3]  0.0-10.0 sec   969 MBytes  96.9 MBytes/sec

c:\iperf>iperf -c 192.168.1.34 -P 1 -i 1 -p 5001 -f M -t 10 -w 64K
------------------------------------------------------------
Client connecting to 192.168.1.34, TCP port 5001
TCP window size: 0.06 MByte
------------------------------------------------------------
[  3] local 192.168.1.35 port 51817 connected with 192.168.1.34 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  92.4 MBytes  92.4 MBytes/sec
[  3]  1.0- 2.0 sec   104 MBytes   104 MBytes/sec
[  3]  2.0- 3.0 sec   102 MBytes   102 MBytes/sec
[  3]  3.0- 4.0 sec   103 MBytes   103 MBytes/sec
[  3]  4.0- 5.0 sec   103 MBytes   103 MBytes/sec
[  3]  5.0- 6.0 sec   103 MBytes   103 MBytes/sec
[  3]  6.0- 7.0 sec   103 MBytes   103 MBytes/sec
[  3]  7.0- 8.0 sec   102 MBytes   102 MBytes/sec
[  3]  8.0- 9.0 sec   103 MBytes   103 MBytes/sec
[  3]  9.0-10.0 sec   104 MBytes   104 MBytes/sec
[  3]  0.0-10.0 sec  1020 MBytes   102 MBytes/sec

Скорость копирования с сервера на клиента - 74мб/с (zfs) 58мб/с (ufs) на файле 2 гига.
Скорость копирования с клиента на сервер (zfs) - 55мб/с на том же файле. Копирует половину быстро и замирает.
Скорость копирования с клиента на сервер (ufs) - 43мб/с на том же файле.

Стало, конечно, гораздо лучше, но не понятна суть происходящего. Почему, например, скорость dd понизилась? При таком высоком результате dd на ufs, копирование на него по сети медленнее, да и внутри сервака с zfs на ufs 55мб/с, а с ufs на zfs 65мб/с?
Есть смысл ещё что-то крутить?)
p.s.Спасибо за терпение!))

Piwis
raidz1-0 ONLINE 0 0 0
gpt/WD-WMC1T1576554 ONLINE 0 0 0
gpt/WD-WCAZAF850805 ONLINE 0 0 0
Покажите zpool history. Мне крайне любопытно как вы делаете raidz из двух дисков.

Piwis
на файле 2 гига
кэш переполнился, началась запись... можно проверить gstat-ом, но его вроде нет в сборке nas4free. из-за этого меньше скорость копирования на диск ufs. там кеш меньше по скольку нету свободной памяти для него. надо бы проверить при копировании загрузку проца, может он не справляется?
тут говорили не давно про то что G2020 "хватает" для zfs. данные с http://www.cpubenchmark.net

Intel Pentium G2020 @ 2.90GHz           2789
AMD Athlon 64 X2 Dual Core 5200+	1361

Сделал себе NAS на Nas4Free (конфигурацию, если надо, опишу подробно). Скорость трансфера файлов по гигабитной сети вроде более-менее приличная, а вот время доступа несколько удручает. При заходе в директорию аппарат "задумывается" на пару секунд, а если файлов много - может и до десятка секунд доходить.

С чем это может быть связано? atime в свойствах датасета отключен.

Xmm...
При заходе в директорию аппарат "задумывается" на пару секунд, а если файлов много - может и до десятка секунд доходить.
С чем это может быть связано?
Обсуждалось чуть ранее. Посмотрите здесь -> NAS своими руками (часть 7), #578

В продолжение вчерашнего поста про RAIDZ2.
Увеличил количество дисков с данными до 16 и провел замеры для RAIDZ1 и RAIDZ2.
Конфигурация аналогична описанной выше.

### RAIDZ1
#disks		total	as9	%	as12	%	delta
3 (2+1)		2T	1.97T	1.5	1.97T	1.5	0T
4 (3+1)		3T	2.95T	1.67	2.86T	4.67	0.09T
5 (4+1)		4T	3.93T	1.75	3.93T	1.75	0T
6 (5+1)		5T	4.90T	2	4.72T	5.6	0.18T
7 (6+1)		6T	5.87T	2.17	5.80T	3.33	0.07T
8 (7+1)		7T	6.84T	2.29	6.63T	5.29	0.21T
9 (8+1)		8T	7.87T	1.63	7.87T	1.63	0T
10 (9+1)	9T	8.81T	2.11	8.75T	2.78	0.06T
11 (10+1)	10T	9.81T	1.9	9.62T	3.8	0.19T
12 (11+1)	11T	10.8T	1.82	10.5T	4.55	0.3T
13 (12+1)	12T	11.8T	1.67	11.4T	5	0.4T
14 (13+1)	13T	12.8T	1.54	12.2T	6.15	0.6T
15 (14+1)	14T	13.7T	2.14	13.1T	6.43	0.6T
16 (15+1)	15T	14.7T	2	14.0T	6.67	0.7T
17 (16+1)	16T	15.7T	1.88	15.7T	1.88	0T

### RAIDZ2
#disks		total	as9	%	as12	%	delta
4 (2+2)		2T	1.96T	2	1.91T	4.5	0.05T
5 (3+2)		3T	2.93T	2.33	2.91T	3	0.02T
6 (4+2)		4T	3.93T	1.75	3.93T	1.75	0T
7 (5+2)		5T	4.90T	2	4.59T	8.2	0.31T
8 (6+2)		6T	5.89T	1.83	5.60T	6.67	0.29T
9 (7+2)		7T	6.87T	1.86	6.75T	3.57	0.12T
10 (8+2)	8T	7.84T	2	7.50T	6.25	0.34T
11 (9+2)	9T	8.80T	2.22	8.25T	8.33	0.55T
12 (10+2)	10T	9.78T	2.2	9.00T	10	0.78T
13 (11+2)	11T	10.7T	2.73	10.5T	4.55	0.2T
14 (12+2)	12T	11.7T	2.5	11.3T	5.83	0.4T
15 (13+2)	13T	12.7T	2.31	12.1T	6.92	0.6T
16 (14+2)	14T	13.7T	2.14	12.9T	7.86	0.8T
17 (15+2)	15T	14.5T	3.33	13.7T	8.67	0.8T
18 (16+2)	16T	15.7T	1.88	15.7T	1.88	0T

где
#disks - количество дисков
total - теоретически доступный объём
as9 и % - свободное место и процент потерь при ashift=9
as12 и % - свободное место и процент потерь при ashift=12
delta - потери места при переходе с ashift=9 на ashift=12

Как видно из первой таблицы, правило "power of two plus parity" хорошо работает для RAIDZ1.
В случае RAIDZ2 не всё так очевидно, там минимальные потери идут при 4+2 и 16+2, при этом 8+2 даёт потери 6.25%.
В разных конфигурациях потери могут составлять до нескольких сотен гигабайт.

Отвечу на свой же вопрос:
пулы на RAIDZ1 и RAIDZ2 на одинаковом количестве дисков с данными (на считая чётность) будут иметь одинаковый размер?
В общем случае - нет.

UPD1.
Напомню, что данные цифры годятся только для примерной оценки потерь.
Диски создавались в VirtualBox размером в 1Тб двоичными (на самом деле, чуть больше - 1026,83 Гб).
Реальные диски имеют меньший размер.
Чтобы посчитать реальные диски, надо умножить размер из таблицы на коэффициент 0.907.
Полученный размер будет ближе к реальным цифрам, но с определенной погрешностью.
Проценты умножать не надо.

Например, RAIDZ2 8+2 при ashift=12 с дисками 2Тб даст свободного места:
7.50 * 2 * 0.907 = 13.605 Тб
Теоретически доступное свободное место:
16 * 0.907 = 14.512 Тб
Потери ZFS:
(14.512 - 13.605) * 1024 = 928.768 Гб

Исправлено: thedix, 04.12.2013 19:32

thedix
Спасибо. Прекрасная работа.

thedix
В общем случае - нет.
ИМХО самое неприятное в истории с ashift 12 это то, что по мере заполнения пула количество "потерянного" объёма будет расти пропорционально количеству записанных файлов (метаинформации).

RU_Taurus
по мере заполнения пула количество "потерянного" объёма будет расти пропорционально количеству записанных файлов (метаинформации)
Хм, вот это интересно бы проверить.
Вроде 1/64 места резервируется по нужды ФС, в том числе под метаданные.

jenci
кэш переполнился, началась запись... можно проверить gstat-ом, но его вроде нет в сборке nas4free.
таки есть

И ещё на нюанс наткнулся: при создании страйпа нужно ко всем дискам .nop делать (не только на первом), иначе на остальных будет ashift=9...

thedix
Хм, вот это интересно бы проверить.
В коде zfs вообще много чего нужно посмотреть и проверить, т.к. "городских легенд" вокруг неё уже бессчётное множество.
Есть кстати англоязычный документ "ZFS on-disk format" и его вольная интерпретация от Юрия Воинова.

Добавление от 04.12.2013 11:08:

Balda2000
при создании страйпа нужно ко всем дискам .nop делать (не только на первом), иначе на остальных будет ashift=9...
Ashift не дискам назначается, а vdev-ам.

2012-07-08.23:00:12 zpool create -m /mnt -O atime=off -O checksum=fletcher4 -O utf8only=on TANK raidz2 
/dev/gpt/d3369.nop /dev/gpt/d5470 /dev/gpt/d3585 /dev/gpt/d5160 /dev/gpt/d5062 /dev/gpt/d6835

# zdb | grep ashift
            ashift: 12
            ashift: 12

RU_Taurus
Покажите zpool history. Мне крайне любопытно как вы делаете raidz из двух дисков.
Я пробовал на nas4free - делается абсолютно непринужденно, никаких допключей и никаких сообщений при этом нету.
в history будет просто

SilverStone CP11 — очень тонкий кабель SATA, который можно подключить даже к разъему, прикрытому картой расширения


защелок не видно

RU_Taurus
Balda2000
при создании страйпа нужно ко всем дискам .nop делать (не только на первом), иначе на остальных будет ashift=9...
Ashift не дискам назначается, а vdev-ам.

2012-07-08.23:00:12 zpool create -m /mnt -O atime=off -O checksum=fletcher4 -O utf8only=on TANK raidz2
/dev/gpt/d3369.nop /dev/gpt/d5470 /dev/gpt/d3585 /dev/gpt/d5160 /dev/gpt/d5062 /dev/gpt/d6835
# zdb | grep ashift
ashift: 12
ashift: 12
Это RAIDZ , а я говорю про STRIPE.
Вот повторил в виртуалке:

zpool create tank /dev/gpt/virt1.nop /dev/gpt/virt2 /dev/gpt/virt3
zdb | grep ashift
ashift: 12
ashift: 9
ashift: 9

Balda2000
Праавильно: у вас страйп из 3х vdev-ов и получается

Oleg Pyzhov
защелок не видно - превосходные кабели miniSAS-4SATA тоже обходятся без защёлок на SATA. И попадались мне говнокабели с защёлками - так что не есть решающий признак.

MikeMac
When writing to a RAID-Z vdev, ZFS may choose to use less than the maximum number of data disks. For example, you may be using a 3+2 (5 disks) RAID-Z2 vdev, but ZFS may choose to write a block as 2+2 because it fits better.
Это всё подтверждает

Balda2000
да я тоже пару страниц назад делал страйп из 8 дисков, тоже пришлось гнопить все диски - иначе только первый ашифт12 становился (забыл написать про это, но это в принципе и логично - ашифт же не к диску относится, а к vdev-у)

MikeMac
цитата (http://constantin.glez.de/blog/2010/06/closer-look-z…erformance#raidz):
When writing to a RAID-Z vdev, ZFS may choose to use less than the maximum number of data disks. For example, you may be using a 3+2 (5 disks) RAID-Z2 vdev, but ZFS may choose to write a block as 2+2 because it fits better.
вот, вот это я и читал и потерял ссылку.....
где то (может тут... надо перечитать) еще писалось что даже на рейде-з-х может бытть выбрана запись миррором вместо контрольной суммы (если блоки очень маленькии или что-то в этом роде...)

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

VDmitry
Ну да... теперь я понял почему так получается... raidz - 1 vdev из 3-х разделов, а в stripe - каждый раздел как отдельный vdev входит... Для меня это было не очевидно... ещё недостаточно хорошо понимаю работу ZFS.

RU_Taurus
Это всё подтверждает да, логика чуть проясняется. Если бы они старались записать каждую запись на все диски - потери были бы при очень большом числе дисков чудовищными.

Есть кстати англоязычный документ "ZFS on-disk format"
RAIDZ там встречается полтора раза, причём ИМХО самое неприятное в истории с ashift 12 это то, что по мере заполнения пула количество "потерянного" объёма будет расти пропорционально количеству записанных файлов (метаинформации).

IMHO это два разных, суммирующихся, процесса - потери места на размазывание записи по нескольким дискам raidz и потери на мелких файлах и метаданных.

Я порядком погуглил и, похоже. вторая проблема как-то описана. А вот первой отцы-основатели не заморачивались (тк дисков на 4K не было). А современные контрибуторы не рискуют лезть в самую глубину движка.

thedix

### RAIDZ1
#disks		total	as9	%	as12	%	delta
5 (4+1)		4T	3.93T	1.75	3.93T	1.75	0T

спасибо вам! я хотел переделать на пул 4+1 на ashift: 9. хорошо что не сделал.
интересно а чем же вызвано такое существенное падение потерь при дисках >12?

MikeMac
ashift ... This is currently '10' for a RAIDz configuration '9 'otherwise
Сделайте скидку на возраст документа он вышел еще во времена существования Sun.

MikeMac
потери места на размазывание записи по нескольким дискам raidz
Этот процесс, на примере, представляю так.
У нас есть гипотетический raidz 4+1. Размер full stripe = 128КБ, размер stripe на каждом диске = 32КБ (128 / 4 дата-диска). Допустим приложение пишет на диск блоками по 64КБ, тогда на каждый записанный блок данных zfs выделит 2 stripe с разных дисков и чётность запишет на третий. То есть весь "динамический размер сегмента" будет ограничен дискретным рядом 32, 64, 96 и 128КБ (плюс чётность на отдельный диск). Если же приложение захочет записать, пусть, 300КБ, то запишутся 2 full stripe и 2 stripe с потерей 52КБ в последнем.

jenci
я хотел переделать на пул 4+1 на ashift: 9. хорошо что не сделал.
Да, вам этого делать не надо.
Владельцам 4+1 и 4+2 повезло больше всех.

интересно а чем же вызвано такое существенное падение потерь при дисках >12?
Сложно объяснить, никакой зависимости не прослеживается.
Меня особенно удивил вариант 8+2 с ashift=12, перепроверял два раза.

Добавление от 04.12.2013 14:27:

RU_Taurus
Этот процесс, на примере, представляю так.
Очень может быть.
Логично, что оставшийся хвост будет уложен в блок, кратный степени двойки., т.к. упрощается распределение свободных блоков.

Добавление от 04.12.2013 14:43:

Кстати, есть предположение, что странные цифры для RAIDZ2 объясняются особенностью применяемого алгоритма.
Напомню, что в RAIDZ1 применяется простой XOR, как в случае обычного RAID5.
Очевидно, что блок чётности будет иметь такой же размер, как и блок данных на каждом диске.
В случае 4+1 это будет 128К / 4 = 32К.
Для RAIDZ2 используется некий расширенный вариант избыточного кодирования Рида-Соломона.
Здесь присутствуют два блока чётности.
Честно говоря, не разбирался в деталях, но очень может быть, что блоки чётности имеют другой размер.
Это может объяснить такие пляски с цифрами.

Исправлено: thedix, 04.12.2013 14:44

MikeMac
Если бы они старались записать каждую запись на все диски - потери были бы при очень большом числе дисков чудовищными.
это точно, учитывая все их рекомендации в стиле возьмем 24 зеркала, добавим охапку (штук 8) SSD на L2ARC и пучок (штуки 4) для ZIL'а, сдобрим все это 200ми гигабайтами РАМа и т.п....
зы. я же писал - файл делится на stripesize и записывается на столько vdev's сколько надо....

thedix
Меня особенно удивил вариант 8+2 с ashift=12, перепроверял два раза.
что там ? а то я как год назад себе сделал такой.... тогда безоговорочно считалось сдесь на форуме что ashift=12 самый кошерный.... счас выесняется что все таки потери в скорости не такие как пространстве (особенно учитывая, что у большинства упирается в гигабит, а почти 1 тера потерь на формате это 1 тера )

RU_Taurus
Этот процесс, на примере, представляю так.
я его вообще уже не представляю.... тут еще вмешивается такой фактор как компрессия (если датасет/пул настроен) - а там вообще муть мутная....
есть куча примеров где народ аналлизирует запись файлов с помощиью zdb -ddddddddddd (сколько там "d" и нахрена столько я не помню).... там можно посмотреть (на пустом пуле) - что куда и как записывается....

зы. с компрессией вообще не понятно? разбивается файл на блоки равные рекордсайзу, а потом они сжимаются ? ну так ясно, что всегда (если данные сжимаемые) будет меньше, и как тогда оно пишется - ведь оно сразу становится не кратно степени 2ки?....
или сжимается маленькими кусочками пока не наберется "целый" рекордсайз из уже сжатых ? или сжимается и проверяется влезет ли в предыдущий по размеру (64к) рекорд-сайз ?

Исправлено: Power User, 04.12.2013 15:10