The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..., opennews (??), 10-Янв-20, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


37. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от Аноним (31), 10-Янв-20, 10:55 
Отличная от других.
Ответить | Правка | Наверх | Cообщить модератору

63. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –2 +/
Сообщение от Аноним (63), 10-Янв-20, 11:23 
Она не столько принципиально отличная, сколько чужеродная. Жаль, что лучше ничего не придумали из проприетарных энтерпрайз фс пока что (raid6 с парити, вот это всё). Это же сколько человекочасов надо чтобы написать аналогичное с нуля, а потом его отшлифовать до продакшен реди состояния? Бтрфс ту же так и не доделали…
Ответить | Правка | Наверх | Cообщить модератору

86. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +2 +/
Сообщение от PnD (??), 10-Янв-20, 12:36 
Нету там ни raid6, ни raid5. Есть n-кратные КС, причём разных типов. Что-то вроде raid3. Поэтому называется "raidz". Сам на этом поначалу накололся. И удивлялся, чего оно работает со скоростью одного НЖМД (в обе стороны).
* Я по этому поводу голосую за "теорию заговора": такой дизайн исключает использование кода 1:1 в SAN.

Есть страйп (raid0) из нескольких raidz. И есть разумный (и раздельный) кэш на запись ("подпирающий" fifo) и чтение (тут сложнее, т.к. 1х "угадайка").
Есть поблочные КС. И это — киллер-фича в сочетании с ssd (все старые реализации raid считают считанные с устройств блоки верными).

Ответить | Правка | Наверх | Cообщить модератору

150. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Ага (?), 10-Янв-20, 17:35 
Не со скоростью, а количеству операций, которые насколько мне помнится ограничиваются самым медленным диском и в обычном raid5/6. Скорость же записи в raidz - растет, пусть и не линейно с ростом количества дисков в массиве.
Ответить | Правка | Наверх | Cообщить модератору

151. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от Аноним (125), 10-Янв-20, 17:37 
>считанные с устройств блоки верными

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

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

253. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 11-Янв-20, 12:24 
> но ведь у дисков уже есть механизм контрольных сумм на блок

...который иногда лажает. Но есть еще кабель от диска до контроллера. И он тоже иногда лажает. Теоретически в SATA там конечно есть CRC, но он не слишком сильный - и поэтому тоже иногда лажает. Контроллер, кстати, возможно тоже иногда лажает. Как впрочем возможно и какое-то еще другое железо, типа шины на мамке...

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

Ответить | Правка | Наверх | Cообщить модератору

273. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (273), 11-Янв-20, 16:17 
T10 ?
Ответить | Правка | Наверх | Cообщить модератору

354. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (-), 13-Янв-20, 14:34 
> T10 ?

Не понимаю. Развейте мысль?

Ответить | Правка | Наверх | Cообщить модератору

315. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Аноним (173), 12-Янв-20, 10:24 
с такой логикой лажать может и процессор, и ОЗУ, и тогда crc на уровне fs не панацея.
Ответить | Правка | К родителю #253 | Наверх | Cообщить модератору

342. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от Аноним (-), 13-Янв-20, 08:33 
> с такой логикой лажать может и процессор, и ОЗУ, и тогда crc
> на уровне fs не панацея.

Валидный пойнт. Но как ни странно, если лажает достаточно откровенно - то и это тоже умеет провоцировать CSUM ERROR. И даже если эти матюки пропустить мимо ушей в каком-то случае, постоянно растущая статистика все же постепенно обратит на себя внимание. Так что по крайней мере будет известно что железо глючное и не будет ложных и чреватых ожиданий.

И кстати как вы думаете, почему придумали ECC RAM и кеши проца, parity/crc на шинах и все такое? А может вы про MCE что-нибудь даже слышали? :)

Ответить | Правка | Наверх | Cообщить модератору

153. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +3 +/
Сообщение от UncleBoB (?), 10-Янв-20, 17:48 
Вы сейчас чушь написали про скорость одного НЖМД

            ZFS Raid Speed Capacity and Performance Benchmarks
                   (speeds in megabytes per second)

1x 4TB, single drive,          3.7 TB,  w=108MB/s , rw=50MB/s  , r=204MB/s
2x 4TB, mirror (raid1),        3.7 TB,  w=106MB/s , rw=50MB/s  , r=488MB/s
2x 4TB, stripe (raid0),        7.5 TB,  w=237MB/s , rw=73MB/s  , r=434MB/s
3x 4TB, mirror (raid1),        3.7 TB,  w=106MB/s , rw=49MB/s  , r=589MB/s
3x 4TB, stripe (raid0),       11.3 TB,  w=392MB/s , rw=86MB/s  , r=474MB/s
3x 4TB, raidz1 (raid5),        7.5 TB,  w=225MB/s , rw=56MB/s  , r=619MB/s
4x 4TB, 2 striped mirrors,     7.5 TB,  w=226MB/s , rw=53MB/s  , r=644MB/s
4x 4TB, raidz2 (raid6),        7.5 TB,  w=204MB/s , rw=54MB/s  , r=183MB/s
5x 4TB, raidz1 (raid5),       15.0 TB,  w=469MB/s , rw=79MB/s  , r=598MB/s
5x 4TB, raidz3 (raid7),        7.5 TB,  w=116MB/s , rw=45MB/s  , r=493MB/s
6x 4TB, 3 striped mirrors,    11.3 TB,  w=389MB/s , rw=60MB/s  , r=655MB/s
6x 4TB, raidz2 (raid6),       15.0 TB,  w=429MB/s , rw=71MB/s  , r=488MB/s
10x 4TB, 2 striped 5x raidz,   30.1 TB,  w=675MB/s , rw=109MB/s , r=1012MB/s
11x 4TB, raidz3 (raid7),       30.2 TB,  w=552MB/s , rw=103MB/s , r=963MB/s
12x 4TB, 6 striped mirrors,    22.6 TB,  w=643MB/s , rw=83MB/s  , r=962MB/s
12x 4TB, 2 striped 6x raidz2,  30.1 TB,  w=638MB/s , rw=105MB/s , r=990MB/s

И так далее

ZFS - это лучшее что есть из ФС в этой солнечной системе. Только, чтобы ощутить все прелести, не нужно ее по под Linux заводить.

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

159. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –4 +/
Сообщение от 6 (?), 10-Янв-20, 18:29 
1) Солнце это имя собтвенное других солнечных нет.
2) Где доказательства - отсутствия 9-й планеты, отсутствия на ней высокоразвитой рассы рептилоидов, отсутствия у них лучших фс

=) пи..бол, расходимся

Ответить | Правка | Наверх | Cообщить модератору

183. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  –1 +/
Сообщение от пох. (?), 10-Янв-20, 21:52 
> Вы сейчас чушь написали про скорость одного НЖМД        
> ZFS Raid Speed Capacity and Performance Benchmarks

и где тут сравнение со скоростью одного диска, без оверхеда zfs? Отож.

Ну и чем это меряли - и в какой конфигурации - тоже отдельный забавный вопрос.

И отдельный - а как вот такого умудрились добиться?
> 4x 4TB, 2 striped mirrors,     7.5 TB,  w=226MB/s , rw=53MB/s  , r=644MB/s
> 4x 4TB, raidz2 (raid6),        7.5 TB,  w=204MB/s , rw=54MB/s  , r=183MB/s

тестировали на pentium mmx ? Или таки архитектурные проблемы на вырожденном случае вылезли очень даже заметно.

> ZFS - это лучшее что есть из ФС в этой солнечной системе.

обитатели Нибиру с вами не вполне согласны.

> Только, чтобы ощутить все прелести, не нужно ее по под Linux
> заводить.

а под чем? На выбор - вечнополоманная freebsd, мертвый солярис, не менее мертвый illumos... э, может вы тоже год zfs с макоси готовы объявить?

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

280. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от Ананимас009 (?), 11-Янв-20, 20:10 
Почитаешь и прям депресняк. Все поломанно или мертво. Как жить?
Ответить | Правка | Наверх | Cообщить модератору

281. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от Аноним (281), 11-Янв-20, 20:32 
не стоит читать комментарии кретинов
Ответить | Правка | Наверх | Cообщить модератору

349. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от PnD (??), 13-Янв-20, 12:52 
> Вы сейчас чушь написали про скорость одного НЖМД

Возможно, про "одного" несколько перегнул. См. ниже.
Но касаемо приведённых замеров, хотелось бы увидеть методику тестирования.

  Что здесь вижу я (по шагам):
> 1x 4TB, single drive,          3.7 TB,  w=108MB/s , rw=50MB/s  , r=204MB/s
> 2x 4TB, mirror (raid1),        3.7 TB,  w=106MB/s , rw=50MB/s  , r=488MB/s

1. Умеем читать оба диска в зеркале по очереди?
2. Тестировали примерно на 50% объёма одного НЖМД. Отсюда подскок выше 100% на зеркале.

> 3x 4TB, mirror (raid1),        3.7 TB,  w=106MB/s , rw=49MB/s  , r=589MB/s

3. Чтение таки не совсем линейное. На 3-х шпинделях попадает хуже. (Или ошибка в реализации ФС)

> 3x 4TB, stripe (raid0),       11.3 TB,  w=392MB/s , rw=86MB/s  , r=474MB/s

4. Маленькие данные? "Пнём об сову" читается существенно хуже.

> 3x 4TB, raidz1 (raid5),        7.5 TB,  w=225MB/s , rw=56MB/s  , r=619MB/s

5. Гоп,стоп. Это что же, 200М/с = скорость *одного* диска? А что тогда надо сделать, чтобы в *два* раза просадить запись?
6. Но даже так не сходится. Ладно, "raid5", 3 диска. *Два* читаем, один→КС. А показанная скорость чтения выше чуть ли не в 1.5 раза.
7. Всё, модель развалилась. Прошу объяснить методику измерений.

** raidz2 (4+2 шпинделя) в raidz2. HGST HUS722T2TALA604. Линейная запись на внешних дорожках у них в районе 160…180 МБ/с afair. L3 кэш записи на Samsung SSD 850 PRO 128GB, зеркало на 4 ГБ.
# bonnie++ ZFS  6x 2TB HDD
mkdir /home/test
chown nobody:nobody /home/test
bonnie++ -u nobody -d /home/test/ -s 51200 -r 8000 -n 0 -b

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
x1.xx-xx.lan    50G   146  99 492821  86 154981  44   357  98 389092  45 212.3  21
Latency             82613us   14348us    1055ms   88732us     507ms     166ms

1.97,1.97,x1.vo-ix.lan,1,1491898455,50G,,146,99,492821,86,154981,44,357,98,389092,45,212.3,21,,,,,,,,,,,,,,,,,,82613us,14348us,1055ms,88732us,507ms,166ms,,,,,,

** ±сравнимая конфигурация на (немолодом) аппаратном raid с 512МБ кэша в DDR.
Внизу — raid6 (5+2).
# bonnie++ ZFS @ LSI MegaRAID SAS 2108  7x 3TB HDD
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
st1             50G    74  99 324079  73 148538  48   154  99 468356  60 234.2   6
Latency               141ms    1527ms     529ms   88479us     383ms     127ms

1.96,1.96,st1,1,1491914042,50G,,74,99,324079,73,148538,48,154,99,468356,60,234.2,6,,,,,,,,,,,,,,,,,,141ms,1527ms,529ms,88479us,383ms,127ms,,,,,,

** А вот так этот же raid работает под "расчётной" нагрузкой:
# bonnie++ ext4 @ LSI MegaRAID SAS 2108  7x 3TB HDD
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bcp1            50G   313  99 799005  94 225400  33   843  99 757494  58 537.1  18
Latency             31092us     149ms     199ms   16939us   50420us   97653us

1.96,1.96,bcp1,1,1491907084,50G,,313,99,799005,94,225400,33,843,99,757494,58,537.1,18,,,,,,,,,,,,,,,,,,31092us,149ms,199ms,16939us,50420us,97653us,,,,,,

Последние 2 замера позволяют примерно оценить вклад zfs в "порчу характеристик".

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

376. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от пох. (?), 20-Янв-20, 17:26 
> Возможно, про "одного" несколько перегнул. См. ниже.
> Но касаемо приведённых замеров, хотелось бы увидеть методику тестирования.

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

> 1. Умеем читать оба диска в зеркале по очереди?

очевидно что наоборот - умеем читать параллельно. А писать - не умеем. (логичненько)

> 2. Тестировали примерно на 50% объёма одного НЖМД. Отсюда подскок выше 100%

причем бы тут объем? Зеркало и должно выдавать 2x на чтение - поскольку блоки читаются параллельно (при нормальной реализации, а не как у linux md)

>> 3x 4TB, mirror (raid1),        3.7 TB,  w=106MB/s , rw=49MB/s  , r=589MB/s
> 3. Чтение таки не совсем линейное. На 3-х шпинделях попадает хуже. (Или

2x3 = 6, что тут не так?

> 5. Гоп,стоп. Это что же, 200М/с = скорость *одного* диска? А что

да.

> тогда надо сделать, чтобы в *два* раза просадить запись?

писать на mirror - двойной объем.

> 6. Но даже так не сходится. Ладно, "raid5", 3 диска. *Два* читаем,

raidz из трех дисков при чтении первращается в страйп на три диска. _три_ читаем, это не дедушкин raid3 с выделенным диском контрольных сумм, который только тупит и тормозит, здесь чтение (при нормальной реализации) идет сразу с трех, поскольку блоки данных равномерно перемешаны с контрольными.

> bonnie++ -u nobody -d /home/test/ -s 51200 -r 8000 -n 0 -b

фаак, мои глазоньки.. ну есть же ж pastebin, не корежащий форматирование...

> Последние 2 замера позволяют примерно оценить вклад zfs в "порчу характеристик".

цифры latency - прямо скажем, странные.
Я бы заподозрил что в первом из этих двух последних работал кэш zfs.


Ответить | Правка | Наверх | Cообщить модератору

377. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +/
Сообщение от PnD (??), 22-Янв-20, 10:50 
> причем бы тут объем?

При том что "подскок *выше* 100". При одинаковом объёме данных, с добавлением шпинделей в массив данные будут съезжать наружу блинов. Добавляя %% к скорости чтения/записи. И уменьшая latency в тестах.

> 2x3 = 6, что тут не так?

То что не совсем 6. Было "лучше чем могло", стало "хуже чем могло". Что дало повод предположить влияние выравнивания данных.

> писать на mirror - двойной объем.

Судя по скоростям, писали не через IDE. И даже старый шедулер с одной очередью на всех в linux не был настолько гуано. Чтобы не уметь параллельную запись. Ну вот разве что в тестовом стенде было ровно одно ядро CPU (которое висело в iowait)?

> raidz из трех дисков при чтении первращается в страйп на три диска.

Оп. Не на два ли? (n+1) жеж.

Ответить | Правка | Наверх | Cообщить модератору

378. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от пох. (?), 22-Янв-20, 11:17 
>> raidz из трех дисков при чтении первращается в страйп на три диска.
> Оп. Не на два ли? (n+1) жеж.

нет. Повторяю - времена raid3 с выделенным "+1" - в глубоком прошлом, именно потому что он был - тормоз. В raidz, как и в raid5/6 данные пишутся на все диски равномерно (как и контрольные блоки - тоже на все примерно поровну), и имеются специальные механизмы выравнивания производительности (чтобы нечаянно не получить снова raid3 ;) Поэтому M*(n+1) последовательных блоков читаются с "n+1" дисков параллельно (а контрольные блоки просто не читаются вообще).

То есть тут результат теста - +- похож на правильный. (и, разумеется, эффективность не в точности n*100%, обязательно будут потери)

Вот как они получили последовательную запись (и хрен с ним с процессором - что, dma тоже отменили?) - это другой вопрос. Возможно, оно так делает на зеркале ради гарантий целостности. Возможно просто баги реализации. А может это так проявляет себя write multiplication. Поскольку у нас нет никакой информации о технике тестирования и сетапе - в любом случае это "anecdotal evidence", поржать можно, надеяться не нужно.

Ответить | Правка | Наверх | Cообщить модератору

290. "Линус Торвальдс пояснил, в чём проблемы реализации ZFS для я..."  +1 +/
Сообщение от pansa2email (?), 12-Янв-20, 01:07 
Про скорость вы не правы.
Увеличиваете кол-во дисков в vdev - увеличиваете линейные параметры.
Увеличиваете кол-во vdev-ов в пуле - увеличиваете Iops'ы.
Вот и вся логика. Из нее, из бюджета, и еще некоторых особенностей формируете конфиг пула, который нужен.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру