forum.opennet.ru

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

Оглавление

Релиз ядра Linux 5.1, opennews (ok), 06-Май-19, (0) [смотреть все]

Хмм-хмм, интересненько, оно только с Nouveau наверное будет работать , EuPhobos (ok), 09:06 , 06-Май-19, (1) –30 //

NVDIMM это совсем не технология NVidia https en wikipedia org wiki NVDIMM, немезидеЦ (?), 09:19 , 06-Май-19, (2) +8
Мои инициалы NV Я тоже принадлежу нвидии , Аноним (4), 09:30 , 06-Май-19, (4) +2 //

Получается так, Николай Владимирович Все мы так понемногу , Аноним (6), 09:55 , 06-Май-19, (6) +10
Yes , анон (?), 10:59 , 06-Май-19, (9) +2

Зачем ты написал это коммент Твоя цель - какова , Аноним (-), 13:06 , 06-Май-19, (35) //

у первопостера нет времени разбираться в вопросе, нужно поскорее что то ляпнуть , Аноним (120), 14:37 , 08-Май-19, (120) +2

репрезентативный уровень икспертизы опеннета, Аноним (44), 14:38 , 06-Май-19, (44) +15

ЩИТО , Аноним (7), 10:11 , 06-Май-19, (7) +2 //

Надо было Kizuna Ai, Аноним (-), 11:12 , 06-Май-19, (12) +10

- зачем оно там и зачем тогда опен либра_ssl , ффф (?), 10:54 , 06-Май-19, (8) +2 //

Скрыто модератором, Штирлиц (?), 11:09 , 06-Май-19, (11) –5 //

Скрыто модератором, А (??), 11:23 , 06-Май-19, (15) +1 //

Скрыто модератором, Аноним (21), 11:46 , 06-Май-19, (21)

Скрыто модератором, Аноним (24), 11:54 , 06-Май-19, (24) +6

Скрыто модератором, Аноним (81), 23:30 , 06-Май-19, (81)

Скрыто модератором, Led (ok), 00:35 , 07-Май-19, (83) +7

171 The idea is for the kernel to handle the symmetric encryption and decrypti, zanswer CCNA RS and S (?), 11:36 , 06-Май-19, (17) +5 //

теперь при атаке человек по средине, если кто-то додумается отправить в ответ 4, КО (?), 13:21 , 06-Май-19, (37) –4 //

Поле Total Length в заголовке IP имеет размер, всего лишь, 16 бит, если что , Аноним (24), 15:06 , 06-Май-19, (46)
Голословное утверждение, Аноним (55), 16:22 , 06-Май-19, (55)
Вы ошибаетесь, когда думаете, что для ядра есть разница, какой размер имеют пере, zanswer CCNA RS and S (?), 09:33 , 07-Май-19, (92) +6

облегчить работу скомпрометированному ядру, Имя (?), 15:45 , 06-Май-19, (52) –3 //

Скомпрометированное ядро и так имеет доступ к памяти всех пользовательских проце, Аноним (55), 16:30 , 06-Май-19, (58)

А что, так можно было COW там только для данных или для метаданных тоже можно н, Аноним (10), 11:06 , 06-Май-19, (10) –2 //

Классический пример zfs-фанбоя - возмущается, что люди предпочитают пилить Btrfs, Fracta1L (ok), 11:22 , 06-Май-19, (14) +4 //

zfs я готов использовать в продакшене хоть сейчас в любой момент Да, там есть н, Аноним (10), 11:42 , 06-Май-19, (18) +8 //

Твои мысли и переживания на этот счёт крайне важны, я думаю что ты должен их нап, Fracta1L (ok), 11:44 , 06-Май-19, (19)

Btrfs лучше работает с зоопарком дисков Разные размеры, добавление по одному, м, Аноним (31), 12:40 , 06-Май-19, (31)

А можно подробнее Я так понимаю, полноценного и рекомендованного к использованию, Stax (ok), 14:05 , 06-Май-19, (40) +2

равное количество ТБ у разных моделей не гарантирует совпадение до байтас пробле, Имя (?), 15:53 , 06-Май-19, (53)

ё-мае, ну zfs не идиоты же писали, в самом деле Там заложено небольшое но дост, Аноним (10), 20:27 , 06-Май-19, (68) +1

есть, но он не работает - к тому же там, по беглому погляду, write hole, как в , нах (?), 10:53 , 07-Май-19, (98)

Она не нужна никому не из-за плохой стабильности, а потому что это фс для сверх , Аноним (-), 12:03 , 06-Май-19, (27)

Угумс Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и л, Stax (ok), 14:16 , 06-Май-19, (41) +2

Классический пример zfs-фанбоя Anonym, Ktoto (?), 14:40 , 06-Май-19, (45)
На сколько мне известно, в ZFS реализация COW сильно отличается от BTRFS Она не, Аноним (-), 15:28 , 06-Май-19, (50)

в ZFS COW на уровне блоков, в brfs на уровне файлов В каком подходе больше овер, Ktoto (?), 16:11 , 06-Май-19, (54) –1

Ну хватит чушь-то нести, иксперты, Fracta1L (ok), 16:24 , 06-Май-19, (57)

Ну просвяти нас, Аноним (-), 17:25 , 06-Май-19, (61) –1

Архитектура ZFS https storagegaga wordpress com tag redirect-on-write сравнени, Ktoto (?), 18:06 , 06-Май-19, (62) –1

Где там хоть слово про Btrfs , Fracta1L (ok), 18:40 , 06-Май-19, (64)

А где там не про Btrfs Я к тому, что выше Вы сделали вброс и так же без каких-л, Аноним (74), 21:46 , 06-Май-19, (74)
Неплохо ты порвался, Fracta1L (ok), 06:38 , 07-Май-19, (86)
Голословное утверждение, Аноним (-), 11:21 , 07-Май-19, (104)
Ты чукча писатель, не читатель и похоже не думатель , Ktoto (?), 09:30 , 07-Май-19, (91)
Там ни одним словом Btrfs не упоминается Тебе его голоса из розетки нашептали , Fracta1L (ok), 11:49 , 07-Май-19, (107)
Там сравнивается архитектура copy-on-write на которой построен BTRFS и redirect-, Ktoto (?), 14:32 , 07-Май-19, (112)

Пока вижу только нотки истерики Но они не истина в последней инстанции Констру, Аноним (-), 11:20 , 07-Май-19, (103)

Отменный доширак на уши , Fracta1L (ok), 16:24 , 06-Май-19, (56) –1

У ZFS 2 вида кеша, часто используемые блоки вымываются хуже На некоторых особых, Аноним (70), 20:32 , 06-Май-19, (70)

Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного бло, Аноним (70), 20:30 , 06-Май-19, (69) +2

Всё верно А для MySQL 16Kb для данных InnoDB и 128Kb для журналов , xm (ok), 20:43 , 06-Май-19, (71)
Эээ нет Я знаю методичку, в которой вы это прочли Но в жизни оно не так Я про, Stax (ok), 08:13 , 07-Май-19, (88) +10

ну хоть один понимает, что делает, а не методички безграмотные перепевает P S , нах (?), 10:42 , 07-Май-19, (96)

Поддержку На днях умерла btrfs после нештатного выключения Умерла полностью С, livelace (?), 18:35 , 06-Май-19, (63) +1

не надо выдавать ваше случайное везение за общее правило И да, что такое умерла, нах (?), 10:47 , 07-Май-19, (97) +1

сейчас он вспомнит что там использовался RAID 5 6 точнее не не вспомнит -, Ktoto (?), 14:35 , 07-Май-19, (113)

насколько я помню давно уже не слышал новостей от пользователей подобного - та, нах (?), 16:02 , 07-Май-19, (115)

вы не видели как zfs pool превращается в тыкву с kernel panic при попытке его им, нах (?), 10:38 , 07-Май-19, (95) +1

Нет В солярке оракловой или одной из открытых Или это в линуксе В целом я вид, Stax (ok), 11:01 , 07-Май-19, (100)

и в линуксе, и в freebsd, результаты примерно одинаковые - и починить не получит, нах (?), 11:29 , 07-Май-19, (105)

ZFS головного мозга Тяжелая болезнь между прочим , Аноним (20), 11:45 , 06-Май-19, (20) +2

Какое отношение имеют разработчики ядра к LinuxZFS , Аноним (24), 11:49 , 06-Май-19, (22) +4

Никогда не понимал при создании какого-то типа или структуры так трудно просчит, InuYasha (?), 11:21 , 06-Май-19, (13) –5 //

Вообще-то 1 января 1970 года Так и представляю, как в 70х да хоть и в 80х год, Аноним (16), 11:33 , 06-Май-19, (16) +4 //

А не обязательно Достаточно структуры с двумя 32-битными числами, обрабатываемы, InuYasha (?), 12:00 , 06-Май-19, (26) –2 //

Проблема не в хранении, а в вычислении Накладные расходы сильно возрастают , Аноним (33), 12:57 , 06-Май-19, (33) +3

И в хранении проблема В те времена память исчислялась килобайтами , Аноним (16), 13:20 , 06-Май-19, (36) +3

Unix time это формат _кодирования_ времени, а не формат хранения В unix time впо, Аноним (55), 16:38 , 06-Май-19, (59) +1

double -- это уже 8 байт, да и польза от плавающей точки тут сомнительная , Аноним (82), 23:38 , 06-Май-19, (82)

Вряд-ли у Вас будут файлы созданные, модифицированные или имевшие последний дост, Совершенно другой аноним (?), 10:05 , 07-Май-19, (93)

Умный Microsoft, например, думал, думал, и придумал у них один из форматов хран, Совершенно другой аноним (?), 09:30 , 07-Май-19, (90) –1
разумеется, никто не думает, что юникс будет использоваться так долго Из книжк, нах (?), 10:56 , 07-Май-19, (99)

Про LZO-RLE в zram ещё добавьте, Аноним (-), 11:52 , 06-Май-19, (23) +1 //

Под новостью есть ссылка исправить , Michael Shigorin (ok), 22:08 , 06-Май-19, (76) –1

А кто-нибудь знает, как обстоят дела с DisplayLink драйверами в ядре , Аноним (25), 11:57 , 06-Май-19, (25)
хорошо, конечно, давно нужно было сделать мне бы эта функция пригодилась ещё гд, Нанобот (ok), 12:04 , 06-Май-19, (28) –2 //

А почему не использовать в этом случае просто UUID для процессов , Аноним (72), 20:58 , 06-Май-19, (72) //

по причине его отсутствия, Нанобот (ok), 08:56 , 07-Май-19, (89)

Linux XP , Аноним (29), 12:21 , 06-Май-19, (29) –3
Единая, быстрая память MRAM или аналоги без разделения на ПЗУ и ОЗУ Это будет, Анимайзер (?), 12:32 , 06-Май-19, (30) //

Это будет новым вызовом нам, храбрейшим и умнейшим сынам каменных джунглей Но м, Ууаа (?), 13:25 , 06-Май-19, (38) +8
Или не придут А если быть точным от этого уже давно ушли Ибо, пока, ограниче, КО (?), 13:35 , 06-Май-19, (39) +1
А перегружаться как , Аноним (102), 11:17 , 07-Май-19, (102) //

memset void 0, 0, total_ram , Аноним (121), 03:35 , 14-Май-19, (121)
Переустановкой виндовс, Ананас (?), 08:18 , 24-Май-19, (122)

Угу-угу Никогда такого не было и вот опять Яблодрочер что-ли Те тоже любят за, uis (ok), 00:00 , 14-Дек-20, (124)

Ну наконец-то Всегда удивлялся отсутствию этой сверхнеобходимой фичи LVMу уж, Аноним (32), 12:46 , 06-Май-19, (32) –1 //

Давай, давай, компиляй ядро без патчей Посмотрим что у тебя отвалится Кажется , Аноним (42), 14:17 , 06-Май-19, (42) –5 //

Это где она билась В смысле, что за дистр , Ordu (ok), 15:20 , 06-Май-19, (49) –1
о каких патчах речь, если не секрет , Аноним (32), 12:25 , 07-Май-19, (108)

Возможность не использовать initramfs была давным-давно Просто так решил вскука, Аноним (43), 14:36 , 06-Май-19, (43) //

Речь шла про корневой раздел на LVM Нужно уж хотя бы выполнить vgchange -ay о, Аноним (24), 15:16 , 06-Май-19, (48) //

Спасибо, Анон , Аноним (32), 12:30 , 07-Май-19, (109)

Хватит добавлять свистоперделок в btrfs Там от того, что уже накреативили - не , Пряникё (?), 15:14 , 06-Май-19, (47) –1
Поскорее бы в bash добавили, Аноним (55), 16:55 , 06-Май-19, (60) –1
Уже откомпилировал работает отлично gentoo-sources-5 1 0 gcc-9 1, просто_дурак_айти_не_мое (?), 21:44 , 06-Май-19, (73)
С патчами dma-buf для KVMGT GVT-G ничего не слышно , DerRoteBaron (ok), 22:04 , 06-Май-19, (75) //

Это тоже вспомнил https looking-glass hostfission com https github com gni, Заря (?), 08:06 , 07-Май-19, (87)

Если кому понадобится чуть более проработанный спек, чем зимний пример в апстрим, Michael Shigorin (ok), 22:10 , 06-Май-19, (77) //

А вы, случайно, не знаете, где можно найти доки по этой библиотеке Быстрый поис, anonymous (??), 22:45 , 06-Май-19, (78) //

Ноль это io_uring_params flags, см io_uring hЯ вот думаю, получится ли с этим с, KonstantinB (ok), 00:43 , 07-Май-19, (84) +1
Более-менее исчерпывающей доки я не нашел, все отправные точки перечислены в пос, KonstantinB (ok), 00:45 , 07-Май-19, (85) +4 //

Спасибо , anonymous (??), 10:32 , 07-Май-19, (94)

Проработанный Все уже лет десять как забыли про такую 171 проработку 187 WTF, Аноним (80), 23:06 , 06-Май-19, (80) +1 //

Для тех, кто в spec-файлах ничего не понимает вроде меня , что тут не так , anonymous (??), 11:11 , 07-Май-19, (101) //

devel для so - явное не так, остальное чьи-то личные тараканы, нах (?), 11:30 , 07-Май-19, (106)

ОК, ещё мне, конечно, не нравится своей экстримальной опасностью строка RP, anonymous (??), 12:59 , 07-Май-19, (111)

Тут не так то, что это всё устаревший мусор, не который при использовании актуал, Аноним (114), 15:25 , 07-Май-19, (114)

Вообще, это очень странный спек для ALT Потому, что в ALT этот устаревший мусор, toshische (ok), 12:27 , 08-Май-19, (117) +1

I m loving it , Аноним (32), 12:34 , 07-Май-19, (110) +1
Да http git altlinux org gears l liburing git p liburing git a blob f gear l, Michael Shigorin (ok), 13:24 , 08-Май-19, (119) //

bolgen os 2 0 , аааа (?), 22:41 , 19-Июн-19, (123) –1

А зачем в этом проработанном спеке столько закатов солнца вручную , toshische (ok), 12:29 , 08-Май-19, (118) +1

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

10. "Релиз ядра Linux 5.1" –2 +/–

Сообщение от Аноним (10), 06-Май-19, 11:06

> В XFS реализован режим always_cow, при котором вместо замены данных в блоках по месту применяется модель COW
А что, так можно было??
COW там только для данных или для метаданных тоже можно?
> В файловой системе Btrfs добавлена возможность настройки уровня сжатия для алгоритма zstd
несколько не по адресу, конечно, но лучше бы в zfs уже zstd добавили, пару лет уже висит https://github.com/zfsonlinux/zfs/issues/6247 и давным-давно патчи готовы, но нет, чем довести это до ума и получить zstd в рабочей и стабильной ФС, некие странные люди предпочитают ковырять далекий от продакшена btrfs.

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

14. "Релиз ядра Linux 5.1" +4 +/–

Сообщение от Fracta1L (ok), 06-Май-19, 11:22

Классический пример zfs-фанбоя - возмущается, что люди предпочитают пилить Btrfs, а не полумёртвую zfs, примотанную к ядру сбоку скотчем.

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

18. "Релиз ядра Linux 5.1" +8 +/–

Сообщение от Аноним (10), 06-Май-19, 11:42

zfs я готов использовать в продакшене хоть сейчас в любой момент. Да, там есть нюансы (связанные как с тем, что это модуль вне ядра, так и прикрученным сбоку к ядру управлением памятью / spl), но тем не менее. Я точно знаю, какой прирост производительности я получу из-за ARC, какую надежность я получу из-за COW, контрольных сумм и прочего. В других задачах - какой объем я получу из-за raidz при отсутствии рисков типичного рейда. И так далее.
А вот кто возьмет btrfs, над тем буду долго смеяться. Вы не видели, как она бьется с потерей данных пользователя? Я видел. Очень по-глупому она может умирать. И не спроста, повисев несколько лет в статусе экспериментальной в RHEL ее в итоге выкинули в статус прекращения поддержки. До лучших времен, которые не факт что наступят.
Проблема btrfs в том, что так и не достигнув стабильности, она оказалась не нужна никому. Даже создатели от нее отказались. Стал доступным рабочий, проверенный годами zfs, к тому же не обладающий некоторыми косяками btrfs. И в своей нише zfs сидит плотно, btfs туда толком войти не может. А в нишу xfs/ext4 btrfs тоже не потянул, принципиальные проблемы как со скоростью, так и со стабильностью. Для обхода проблем с производительностью предлагают атрибут для отключения COW - это же курам на смех. Типа "ну да, так вы теряете почти все преимущества, зато формально все еще можете хвастаться знакомым админам, что используете btrfs, ура-ура!"

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

19. "Релиз ядра Linux 5.1" +/–

Сообщение от Fracta1L (ok), 06-Май-19, 11:44

Твои мысли и переживания на этот счёт крайне важны, я думаю что ты должен их написать в письме разработчикам ядра, чтобы они перестали заниматься Btrfs и засели за ZFS.

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

31. "Релиз ядра Linux 5.1" +/–

Сообщение от Аноним (31), 06-Май-19, 12:40

Btrfs лучше работает с зоопарком дисков. Разные размеры, добавление по одному, можно даже убрать диск и не заменять. В датацентрах это не нужно, а дома нужно.

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

40. "Релиз ядра Linux 5.1" +2 +/–

Сообщение от Stax (ok), 06-Май-19, 14:05

> Btrfs лучше работает с зоопарком дисков. Разные размеры, добавление по одному, можно даже убрать диск и не заменять. В датацентрах это не нужно, а дома нужно.
А можно подробнее?
Я так понимаю, полноценного и рекомендованного к использованию аналога raid-z/2/3 в btrfs нет. Но какие-либо ограничения на установку диска меньшего размера в zfs присутствуют только в этом случае. Большего размера, кстати, без проблем можно.
Если мы говорим не про raidz, а про любую другую конфигурацию пула из нескольких vdev (например, страйп зеркал, как наиболее типичный в продакшене), то там не накладывается никаких ограничений. Хоть дешевые флешки подмешивать в пул. Большие, маленькие, добавлять и заменять по одному - никаких ограничений (ну, точнее есть одно естественное ограничение - если у нас страйп из зеркальных пар, то при замене одного из дисков в паре новый должен быть не меньше старого. Но ведь никто не запрещает заменить диск в другой паре либо же добавить новую, можно даже из одного этого диска). Производительность будет, конечно, не ахти, т.к. zfs будет размазывать данные по vdev'ам разных размеров так, чтобы был примерно похожий % заполненности на каждом, что приведет к перекосу IOPS'ов, на диски большего размера их будет попадать куда больше. Но тут уж се ля ви.
> можно даже убрать диск и не заменять
А где нельзя-то? Никто не мешает в zfs заоффлайнить диск, хоть рабочий хоть мертвый, и так и жить до возможности замены. Если при этом в принципе можно восстановить данные (за счет зеркала либо raidz), то пул будет работать как ни в чем не бывало.
А вообще, с *настоящим* зоопарком дисков с возможностью делать почти что угодно могут работать только штуки типа Unraid, к сожалению.

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

53. "Релиз ядра Linux 5.1" +/–

Сообщение от Имя (?), 06-Май-19, 15:53

>диска меньшего размера
равное количество ТБ у разных моделей не гарантирует совпадение до байта
>Большего размера, кстати, без проблем можно.
с проблемами, место пропадает

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

68. "Релиз ядра Linux 5.1" +1 +/–

Сообщение от Аноним (10), 06-Май-19, 20:27

> равное количество ТБ у разных моделей не гарантирует совпадение до байта
ё-мае, ну zfs не идиоты же писали, в самом деле! Там заложено небольшое (но достаточное) округление вниз, чтобы не иметь этой проблемы - как и на любом аппаратном рейде. Другое дело, что реализация этого, насколько я помню, чуть отличается в исходном солярисе и в zfsonlinux.
Конкретно ZoL при добавлении диска создает там GPT-разделы, автоматически отрезая до 10 мегабайт с конца (выделяя их в отдельный неиспользуемый раздел), и разница между дисками в рамках 10 мегабайт ничего не изменит.
> с проблемами, место пропадает
Ну в качестве временного решения ) А место пропадает только пока второй диск в зеркале так же не заменят на больший. И тут место-таки возвращается.

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

98. "Релиз ядра Linux 5.1" +/–

Сообщение от нах (?), 07-Май-19, 10:53

> Я так понимаю, полноценного и рекомендованного к использованию аналога raid-z/2/3 в btrfs нет.
есть, но он не работает ;-)
к тому же там, по беглому погляду, write hole, как в "лучших" домах, zfs даже на raidz3 будет быстрее.
а для дома я бы ни на той, ни на другой не рисковал ползучими апгрейдами дисков - учитывая, как оно все работает, единственно-правильный апгрейд - zfs send на новую пару или новый raidz. Можно изначально degraded - на первых порах старая поработает архивом.

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

27. "Релиз ядра Linux 5.1" +/–

Сообщение от Аноним (-), 06-Май-19, 12:03

Она не нужна никому не из-за плохой стабильности, а потому что это фс для сверх быстрых снепшотов, которые реализованы в угоду общей производительности. Снепшоты, разумеется, нужны не всем. Базу на ней не покрутишь, и систему ставить тоже никто не будет. А вот для файлопомойки она самое то. Проще говоря, у нее просто узкая специализация.

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

41. "Релиз ядра Linux 5.1" +2 +/–

Сообщение от Stax (ok), 06-Май-19, 14:16

> Она не нужна никому не из-за плохой стабильности, а потому что это
> фс для сверх быстрых снепшотов, которые реализованы в угоду общей производительности.
> Снепшоты, разумеется, нужны не всем. Базу на ней не покрутишь, и
Угумс. Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и лучше работает, чем на ext4/zfs. Хоть там и COW и все остальное. Потому что во-первых сжатие обычно очень хорошо работает для таблиц (на том же постгресе коэффициент сжатия для lz4 в zfs порядка 2-3 при блоках 32k - влегкую), что при многих шаблонах работы позволяет хорошо экономить IOPS'ы. А во-вторых ARC с его раздельным кэшем часто используемых и последних используемых данных это просто бомба по сравнению со штатным кэшем линукса, которых для данных умеет кэшировать только последнее использование.
Может если у вас Оракл то можно и без этого, там свои умные кэши вместо системных, но у постгри, полагающейся на системный кэш просто крылья появляются при использовании ARC вместо обычной реализации.

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

45. "Релиз ядра Linux 5.1" +/–

Сообщение от Ktoto (?), 06-Май-19, 14:40

"Классический пример zfs-фанбоя" @Anonym

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

50. "Релиз ядра Linux 5.1" +/–

Сообщение от Аноним (-), 06-Май-19, 15:28

На сколько мне известно, в ZFS реализация COW сильно отличается от BTRFS. Она не захлёбывается на виртуалках или бд, но при этом использует агрессивное кеширование в память. И памяти ей нужно много.

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

54. "Релиз ядра Linux 5.1" –1 +/–

Сообщение от Ktoto (?), 06-Май-19, 16:11

в ZFS COW на уровне блоков, в brfs на уровне файлов. В каком подходе больше оверхеда, в каком то больше возможностей.

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

57. "Релиз ядра Linux 5.1" +/–

Сообщение от Fracta1L (ok), 06-Май-19, 16:24

>в ZFS COW на уровне блоков, в brfs на уровне файлов
Ну хватит чушь-то нести, иксперты

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

61. "Релиз ядра Linux 5.1" –1 +/–

Сообщение от Аноним (-), 06-Май-19, 17:25

Ну просвяти нас

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

62. "Релиз ядра Linux 5.1" –1 +/–

Сообщение от Ktoto (?), 06-Май-19, 18:06

Архитектура ZFS:
https://storagegaga.wordpress.com/tag/redirect-on-write/
сравнение с btrfs :
https://storageswiss.com/2016/04/01/snapshot-101-copy-on-wri.../

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

64. "Релиз ядра Linux 5.1" +/–

Сообщение от Fracta1L (ok), 06-Май-19, 18:40

> сравнение с btrfs :
> https://storageswiss.com/2016/04/01/snapshot-101-copy-on-wri.../
Где там хоть слово про Btrfs?

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

74. "Релиз ядра Linux 5.1" +/–

Сообщение от Аноним (74), 06-Май-19, 21:46

А где там не про Btrfs? Я к тому, что выше Вы сделали вброс:
> Ну хватит чушь-то нести, иксперты
и так же без каких-либо аргументов или пояснений

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

86. "Релиз ядра Linux 5.1" +/–

Сообщение от Fracta1L (ok), 07-Май-19, 06:38

Неплохо ты порвался

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

104. "Релиз ядра Linux 5.1" +/–

Сообщение от Аноним (-), 07-Май-19, 11:21

Голословное утверждение

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

91. "Релиз ядра Linux 5.1" +/–

Сообщение от Ktoto (?), 07-Май-19, 09:30

Ты чукча писатель, не читатель ?
и похоже не думатель ...

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

107. "Релиз ядра Linux 5.1" +/–

Сообщение от Fracta1L (ok), 07-Май-19, 11:49

Там ни одним словом Btrfs не упоминается. Тебе его голоса из розетки нашептали?

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

112. "Релиз ядра Linux 5.1" +/–

Сообщение от Ktoto (?), 07-Май-19, 14:32

Там сравнивается архитектура copy-on-write на которой построен BTRFS и redirect-on-write на которой построен ZFS.
Таки ты писатель, а не читатель!

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

103. "Релиз ядра Linux 5.1" +/–

Сообщение от Аноним (-), 07-Май-19, 11:20

Пока вижу только нотки истерики. Но они не истина в последней инстанции. Конструктивная мы не дождемся?

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

56. "Релиз ядра Linux 5.1" –1 +/–

Сообщение от Fracta1L (ok), 06-Май-19, 16:24

>Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и лучше работает, чем на ext4/zfs
Отменный доширак на уши.

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

70. "Релиз ядра Linux 5.1" +/–

Сообщение от Аноним (70), 06-Май-19, 20:32

У ZFS 2 вида кеша, часто используемые блоки вымываются хуже. На некоторых особых сценариях работы базы это может выстрелить.

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

69. "Релиз ядра Linux 5.1" +2 +/–

Сообщение от Аноним (70), 06-Май-19, 20:30

Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного блока базой с диска поднимается информация из 4-х и 3 из них засоряют кеш. Пишется тоже много лишнего... Блок ФС должен быть равен рабочему блоку базы (8к). Кеш данных нужно выключать. Можно врубить L2ARС, возможно от него будет прок, от журнала на SSD явно прок будет, но ARC для ФС с данным базы нужно отключить и дать больше шареной памяти, постгря сама придумает, что с этой памятью делать. Ну если это сервер БД, а не БД на домашнем сервере с ещё десятком сервисов... Это всё ИМХО конечно, но всё же...

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

71. "Релиз ядра Linux 5.1" +/–

Сообщение от xm (ok), 06-Май-19, 20:43

> Блок ФС должен быть равен рабочему блоку базы (8к)
Всё верно. А для MySQL 16Kb для данных InnoDB и 128Kb для журналов.

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

88. "Релиз ядра Linux 5.1" +10 +/–

Сообщение от Stax (ok), 07-Май-19, 08:13

> Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного блока базой с диска поднимается информация из 4-х и 3 из них засоряют кеш
Эээ нет. Я знаю методичку, в которой вы это прочли. Но в жизни оно не так. Я пробовал и 8к, конечно же. Но 32 или даже 64 лучше (по всем реальным бенчмаркам в моих ситуациях 64 еще лучше, но тут уж я испугался и "сконсервативничал"). Во всяком случае, для SSD это точно так.
Во-первых, на засорение кэша в памяти - по фигу. В моих шаблонах, к примеру, 128 ГБ машины (где примерно 80 под ARC) достаточно для хорошо нагруженной базы на пару-тройку терабайт. Никаких эффектов нехватки кэша не наблюдается. Хотя для еще больших баз и сверхбольших нагрузок, вероятно, лучше еще памяти.
Во-вторых критичное тут IO. Я писал, что база получает огромный прирост скорости от сжатия, т.к. получается за то же время вытянуть больше данных. Но на маленьких блоках сжатие перестает работать. Вот пример цифр как раз для постгри: https://www.2ndquadrant.com/en/blog/pg-phriday-postgres-zfs/
Коэффициент сжатия 1.71 при 8к блоках против 7.59 при 128к. Или можно так представить: тратя в 4.4 раза больше времени, мы прочитываем в 16 раз больше данных (временем разжатия можно пренебречь). Но нагрузки от БД по чтению не являются случайными! Даже в OLTP процент чисто случайных выборок, когда каждый следующий блок не имеет отношения к предыдущему не такой большой. А в других нагрузках так постоянно БД приходится считывать последовательные куски - таблиц или индексов. И это как бы правда, что при считывании истинно случайных блоков мы будем тупо тратить в несколько раз больше времени. Но каждый раз, когда требуются последовательные блоки, мы за то же время считываем в разы больше информации.
Ну и в-третьих, помимо сжатия считать более крупный блок эффективнее, чем два мелких последовательно. А в базе последовательной нагрузки не так мало, как писал выше (даже если кажется, что это не так!).
Но надо заметить, что recordsize в zfs это не фиксация, а ограничение сверху. Поэтому если база будет активно писать или изменять случайные 8K блоки (в противоположность последовательной записи), то эти измененные блоки будут сохранться по 8K, что бы там в recordsize не стояло. Ну и оверхед будет при изменениях. Поэтому эффект от регулярного pg_repack для переписывания таблиц и индексов для постгри на zfs даже больше, чем в других ситуациях (в целом-то это много когда улучшает производительность). Прямо видно, как уменьшаются размеры на диске и увеличивается коэффициент сжатия и производительность - пишет-то постгрес своими блоками, но zfs последовательные записи (даже в несколько потоков) агрегирует и пишет своим recordsize.
Цифр по постгресу, показывающих это на практике в каком-нибудь pgbench я в сети сейчас не вижу, а вот по mysql вполне находятся (где ситуация похожая): https://charlesnagy.info/it/mysql/how-to-decrease-iops-when-...- 16k лучше, чем 8, а 32k еще лучше.
В общем, те люди, которые писали ту методичку скорее всего не учитывали, что придут SSD, не оценивали эффект от сжатия и в целом не пробовали гонять ни реальную нагрузку, ни хотя бы pgbench в современных реалиях ) Потому что методичка с советом брать recordsize=8k для постгри родом где-то из 2012 или 13 года, с тех пор многими бездумно копировалась, да и вообще не факт что авторы реально проверяли это все для постгри, а не скопировали с оракала по аналогии (а там ситуация немного другая, т.к. во-первых он не MVCC, а во-вторых там свое кэширование, а не системное).
> Кеш данных нужно выключать
)) попробуйте как-нибудь на досуге, будет очень смешно. Сейчас не готов показать цифры, но по памяти как-то так: когда работают несколько очень тяжелых запросов, надолго прогружающих диски, с включенным кэшем имеем 20 МБ/с случайных чтений на диск (NVMe дисков тогда возможности поставить не было, а это где-то предел энтерпрайзных SATA SSD'шников типа DC 3700 под долговременной нагрузкой). Видно, как дискам плохо, задержки (await) немаленькие. Ставим primarycache=metadata. О! У дисков открывается второе дыхание, ввод-вывод становится более-менее последовательным, они фигачат под 120 МБ/с. Задержки уменьшаются, все счастливы. Кроме пользователей: запросы начинают выполняться в несколько раз дольше. Опаньки.
С другой стороны, та база была реальный хардкор. На более приличных экземплярах переход на ZFS и эффект от умного ARC + сжатия обычно настолько делает все легче, что выключайте что угодно, все равно скорее всего будет лучше, чем было до zfs.
> Можно врубить L2ARС
В базах, где я вынужден был перейти на zfs этап L2ARC давно пройден, т.к. хотсет превышает разумный объем SSD под L2ARC, они давно all-SSD. Хотя на начальных этапах в некоторых из них это работало. Но когда база на много терабайт и это не разу ни холодные данные, все это постоянно читается и пишется, L2ARC не работает.

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

96. "Релиз ядра Linux 5.1" +/–

Сообщение от нах (?), 07-Май-19, 10:42

ну хоть один понимает, что делает, а не методички (безграмотные) перепевает.
P.S. те люди что их писали - еще и не отличали работу ARC от prefetch. А это _разные_ механизмы и управляются они по отдельности (нет, не надо его выключать, будет хуже)
P.P.S. при включении сжатия у вас размер блока - переменный. Хотите фиксированных блоков "как в методичке" - отключайте сжатие. (разумеется, станет хуже ;-)

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

63. "Релиз ядра Linux 5.1" +1 +/–

Сообщение от livelace (?), 06-Май-19, 18:35

Поддержку. На днях умерла btrfs после нештатного выключения. Умерла полностью. Самое интересное, что данные на данном томе вообще не использовались в тот момент. ФС на сервере: ext4 под систему, xfs под openstack swift, zfs под виртуальные машины. Выжили все, кроме btrfs.

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

97. "Релиз ядра Linux 5.1" +1 +/–

Сообщение от нах (?), 07-Май-19, 10:47

не надо выдавать ваше случайное везение за общее правило.
И да, что такое "умерла полностью" - что говорит mount и что показывает check ? (про dump-tree лучше не буду, все равно не разберетесь)

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

113. "Релиз ядра Linux 5.1" +/–

Сообщение от Ktoto (?), 07-Май-19, 14:35

сейчас он вспомнит что там использовался RAID 5/6 ... точнее не . не вспомнит :-)

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

115. "Релиз ядра Linux 5.1" +/–

Сообщение от нах (?), 07-Май-19, 16:02

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

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

95. "Релиз ядра Linux 5.1" +1 +/–

Сообщение от нах (?), 07-Май-19, 10:38

> Вы не видели, как она бьется с потерей данных пользователя? Я видел.
вы не видели как zfs pool превращается в тыкву с kernel panic при попытке его импорта/отрытия уже импортированного, похоронив ВСЕ данные вообще?
Я вас огорчу, но вы ничерта, похоже, не знаете о предмете своего фетишизирования.
> Проблема btrfs в том, что так и не достигнув стабильности, она оказалась не нужна никому.
проблема zfs в том, что потеряв сановского тимлида с большой дубиной, она оказалась "нужна" массе торопыжных обезьянков, пильщиков грантов, которые сломали все что можно и нельзя, под предлогом мелкого улучшизма, и не сделали ничего из того что действительно надо было сделать - под предлогом "а у сана такого нет!".

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

100. "Релиз ядра Linux 5.1" +/–

Сообщение от Stax (ok), 07-Май-19, 11:01

>> Вы не видели, как она бьется с потерей данных пользователя? Я видел.
> вы не видели как zfs pool превращается в тыкву с kernel panic
> при попытке его импорта/отрытия уже импортированного, похоронив ВСЕ данные вообще?
Нет. В солярке оракловой или одной из открытых? Или это в линуксе? В целом я видел довольно экзотические проблемы с пулами, вызванные либо проблемами железа, либо странными манипуляциями с дисками при замене, но всегда решение находилось.
А почему в тыкву? Если данные физически на диске не бьются (а с чего им биться, там же транзакции?) и можно попробовать еще раз?
Ну а то, что в линуксе нет безопасного отладчика ядра типа mdb и оно чуть что так в панику - это как бы не вина zfs...
> проблема zfs в том, что потеряв сановского тимлида с большой дубиной, она
> оказалась "нужна" массе торопыжных обезьянков, пильщиков грантов, которые сломали все
> что можно и нельзя, под предлогом мелкого улучшизма, и не сделали
> ничего из того что действительно надо было сделать - под предлогом
> "а у сана такого нет!".
Хм. Ну кое-что полезное все-таки сделали. Большие блоки и шифрование (да-да, обе фичи появились в оракловой солярке после форка, но в открытую-то их пришлось заново добавлять) очень порадовали, discard для zvol (а этого и в оракловой нет! Правда, 11.4 я не щупал, но скорее всего тоже нет..) тоже полезен. LZ4 опять же раньше прикрутили.
А что по-вашему "надо было сделать"? Block pointer rewrite, который лучшие сановские умы не смогли даже спроектировать толком? Это "торопыжных обезьянков, пильщиков грантов" не сделают никогда, думаю.

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

105. "Релиз ядра Linux 5.1" +/–

Сообщение от нах (?), 07-Май-19, 11:29

> Нет. В солярке оракловой или одной из открытых? Или это в линуксе?
и в линуксе, и в freebsd, результаты примерно одинаковые - и починить не получится просто так.
> А почему в тыкву? Если данные физически на диске не бьются (а с чего им биться, там же
случаи разные бывают - например, нештатное отключение питания подачей 380 на вход упса - все что тот мог делать, это отключиться, не спалив все к чертям совсем. Причем раз пронесет, и второй пронесет, а на третий заглянет полярная лисичка - http://www.michellesullivan.org/blog/1726 (не Лена, но не надо читать весь блог. Я предупреждал.)
> транзакции?) и можно попробовать еще раз?
еще раз kernel panic случится. Ситуация воспроизводима 100%
разработчики (во фре, им пытались такое сдавать) не считают это _своей_ проблемой - "удалите пул и пересоздайте". Они даже не заинтересовались возможностью получить его копию (это непросто и там личная информация, но технически - возможно, владелец сохранил этот прекрасный образчик для тестов) - не за то грантец-то пилится.
> Ну а то, что в линуксе нет безопасного отладчика ядра типа mdb
тут скорее zdb нужен - но не тот что в линуксе, а с возможностью просмотра и правки on-disk управляющих структур на неимпортированном (panic!) пуле. В процессе приобретется много-много ненужных знаний о внутреннем ее устройстве.
В любом случае это уже совсем непохоже на невинную детскую игру в крысу, если пул был для чего-то полезного.

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

20. "Релиз ядра Linux 5.1" +2 +/–

Сообщение от Аноним (20), 06-Май-19, 11:45

ZFS головного мозга. Тяжелая болезнь между прочим.

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

22. "Релиз ядра Linux 5.1" +4 +/–

Сообщение от Аноним (24), 06-Май-19, 11:49

Какое отношение имеют разработчики ядра к LinuxZFS ?

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

10. "Релиз ядра Linux 5.1"	–2 +/–
Сообщение от Аноним (10), 06-Май-19, 11:06
> В XFS реализован режим always_cow, при котором вместо замены данных в блоках по месту применяется модель COW А что, так можно было?? COW там только для данных или для метаданных тоже можно? > В файловой системе Btrfs добавлена возможность настройки уровня сжатия для алгоритма zstd несколько не по адресу, конечно, но лучше бы в zfs уже zstd добавили, пару лет уже висит https://github.com/zfsonlinux/zfs/issues/6247 и давным-давно патчи готовы, но нет, чем довести это до ума и получить zstd в рабочей и стабильной ФС, некие странные люди предпочитают ковырять далекий от продакшена btrfs.
Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Релиз ядра Linux 5.1"	+4 +/–
	Сообщение от Fracta1L (ok), 06-Май-19, 11:22
	Классический пример zfs-фанбоя - возмущается, что люди предпочитают пилить Btrfs, а не полумёртвую zfs, примотанную к ядру сбоку скотчем.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Релиз ядра Linux 5.1"	+8 +/–
	Сообщение от Аноним (10), 06-Май-19, 11:42
	zfs я готов использовать в продакшене хоть сейчас в любой момент. Да, там есть нюансы (связанные как с тем, что это модуль вне ядра, так и прикрученным сбоку к ядру управлением памятью / spl), но тем не менее. Я точно знаю, какой прирост производительности я получу из-за ARC, какую надежность я получу из-за COW, контрольных сумм и прочего. В других задачах - какой объем я получу из-за raidz при отсутствии рисков типичного рейда. И так далее. А вот кто возьмет btrfs, над тем буду долго смеяться. Вы не видели, как она бьется с потерей данных пользователя? Я видел. Очень по-глупому она может умирать. И не спроста, повисев несколько лет в статусе экспериментальной в RHEL ее в итоге выкинули в статус прекращения поддержки. До лучших времен, которые не факт что наступят. Проблема btrfs в том, что так и не достигнув стабильности, она оказалась не нужна никому. Даже создатели от нее отказались. Стал доступным рабочий, проверенный годами zfs, к тому же не обладающий некоторыми косяками btrfs. И в своей нише zfs сидит плотно, btfs туда толком войти не может. А в нишу xfs/ext4 btrfs тоже не потянул, принципиальные проблемы как со скоростью, так и со стабильностью. Для обхода проблем с производительностью предлагают атрибут для отключения COW - это же курам на смех. Типа "ну да, так вы теряете почти все преимущества, зато формально все еще можете хвастаться знакомым админам, что используете btrfs, ура-ура!"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Fracta1L (ok), 06-Май-19, 11:44
	Твои мысли и переживания на этот счёт крайне важны, я думаю что ты должен их написать в письме разработчикам ядра, чтобы они перестали заниматься Btrfs и засели за ZFS.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (31), 06-Май-19, 12:40
	Btrfs лучше работает с зоопарком дисков. Разные размеры, добавление по одному, можно даже убрать диск и не заменять. В датацентрах это не нужно, а дома нужно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Релиз ядра Linux 5.1"	+2 +/–
	Сообщение от Stax (ok), 06-Май-19, 14:05
	> Btrfs лучше работает с зоопарком дисков. Разные размеры, добавление по одному, можно даже убрать диск и не заменять. В датацентрах это не нужно, а дома нужно. А можно подробнее? Я так понимаю, полноценного и рекомендованного к использованию аналога raid-z/2/3 в btrfs нет. Но какие-либо ограничения на установку диска меньшего размера в zfs присутствуют только в этом случае. Большего размера, кстати, без проблем можно. Если мы говорим не про raidz, а про любую другую конфигурацию пула из нескольких vdev (например, страйп зеркал, как наиболее типичный в продакшене), то там не накладывается никаких ограничений. Хоть дешевые флешки подмешивать в пул. Большие, маленькие, добавлять и заменять по одному - никаких ограничений (ну, точнее есть одно естественное ограничение - если у нас страйп из зеркальных пар, то при замене одного из дисков в паре новый должен быть не меньше старого. Но ведь никто не запрещает заменить диск в другой паре либо же добавить новую, можно даже из одного этого диска). Производительность будет, конечно, не ахти, т.к. zfs будет размазывать данные по vdev'ам разных размеров так, чтобы был примерно похожий % заполненности на каждом, что приведет к перекосу IOPS'ов, на диски большего размера их будет попадать куда больше. Но тут уж се ля ви. > можно даже убрать диск и не заменять А где нельзя-то? Никто не мешает в zfs заоффлайнить диск, хоть рабочий хоть мертвый, и так и жить до возможности замены. Если при этом в принципе можно восстановить данные (за счет зеркала либо raidz), то пул будет работать как ни в чем не бывало. А вообще, с настоящим зоопарком дисков с возможностью делать почти что угодно могут работать только штуки типа Unraid, к сожалению.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Имя (?), 06-Май-19, 15:53
	>диска меньшего размера равное количество ТБ у разных моделей не гарантирует совпадение до байта >Большего размера, кстати, без проблем можно. с проблемами, место пропадает
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Релиз ядра Linux 5.1"	+1 +/–
	Сообщение от Аноним (10), 06-Май-19, 20:27
	> равное количество ТБ у разных моделей не гарантирует совпадение до байта ё-мае, ну zfs не идиоты же писали, в самом деле! Там заложено небольшое (но достаточное) округление вниз, чтобы не иметь этой проблемы - как и на любом аппаратном рейде. Другое дело, что реализация этого, насколько я помню, чуть отличается в исходном солярисе и в zfsonlinux. Конкретно ZoL при добавлении диска создает там GPT-разделы, автоматически отрезая до 10 мегабайт с конца (выделяя их в отдельный неиспользуемый раздел), и разница между дисками в рамках 10 мегабайт ничего не изменит. > с проблемами, место пропадает Ну в качестве временного решения ) А место пропадает только пока второй диск в зеркале так же не заменят на больший. И тут место-таки возвращается.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Релиз ядра Linux 5.1"	+/–
	Сообщение от нах (?), 07-Май-19, 10:53
	> Я так понимаю, полноценного и рекомендованного к использованию аналога raid-z/2/3 в btrfs нет. есть, но он не работает ;-) к тому же там, по беглому погляду, write hole, как в "лучших" домах, zfs даже на raidz3 будет быстрее. а для дома я бы ни на той, ни на другой не рисковал ползучими апгрейдами дисков - учитывая, как оно все работает, единственно-правильный апгрейд - zfs send на новую пару или новый raidz. Можно изначально degraded - на первых порах старая поработает архивом.
	Ответить \| Правка \| К родителю #40 \| Наверх \| Cообщить модератору


	27. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (-), 06-Май-19, 12:03
	Она не нужна никому не из-за плохой стабильности, а потому что это фс для сверх быстрых снепшотов, которые реализованы в угоду общей производительности. Снепшоты, разумеется, нужны не всем. Базу на ней не покрутишь, и систему ставить тоже никто не будет. А вот для файлопомойки она самое то. Проще говоря, у нее просто узкая специализация.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	41. "Релиз ядра Linux 5.1"	+2 +/–
	Сообщение от Stax (ok), 06-Май-19, 14:16
	> Она не нужна никому не из-за плохой стабильности, а потому что это > фс для сверх быстрых снепшотов, которые реализованы в угоду общей производительности. > Снепшоты, разумеется, нужны не всем. Базу на ней не покрутишь, и Угумс. Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и лучше работает, чем на ext4/zfs. Хоть там и COW и все остальное. Потому что во-первых сжатие обычно очень хорошо работает для таблиц (на том же постгресе коэффициент сжатия для lz4 в zfs порядка 2-3 при блоках 32k - влегкую), что при многих шаблонах работы позволяет хорошо экономить IOPS'ы. А во-вторых ARC с его раздельным кэшем часто используемых и последних используемых данных это просто бомба по сравнению со штатным кэшем линукса, которых для данных умеет кэшировать только последнее использование. Может если у вас Оракл то можно и без этого, там свои умные кэши вместо системных, но у постгри, полагающейся на системный кэш просто крылья появляются при использовании ARC вместо обычной реализации.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Ktoto (?), 06-Май-19, 14:40
	"Классический пример zfs-фанбоя" @Anonym
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (-), 06-Май-19, 15:28
	На сколько мне известно, в ZFS реализация COW сильно отличается от BTRFS. Она не захлёбывается на виртуалках или бд, но при этом использует агрессивное кеширование в память. И памяти ей нужно много.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	54. "Релиз ядра Linux 5.1"	–1 +/–
	Сообщение от Ktoto (?), 06-Май-19, 16:11
	в ZFS COW на уровне блоков, в brfs на уровне файлов. В каком подходе больше оверхеда, в каком то больше возможностей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Fracta1L (ok), 06-Май-19, 16:24
	>в ZFS COW на уровне блоков, в brfs на уровне файлов Ну хватит чушь-то нести, иксперты
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Релиз ядра Linux 5.1"	–1 +/–
	Сообщение от Аноним (-), 06-Май-19, 17:25
	Ну просвяти нас
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Релиз ядра Linux 5.1"	–1 +/–
	Сообщение от Ktoto (?), 06-Май-19, 18:06
	Архитектура ZFS: https://storagegaga.wordpress.com/tag/redirect-on-write/ сравнение с btrfs : https://storageswiss.com/2016/04/01/snapshot-101-copy-on-wri.../
	Ответить \| Правка \| Наверх \| Cообщить модератору


	64. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Fracta1L (ok), 06-Май-19, 18:40
	> сравнение с btrfs : > https://storageswiss.com/2016/04/01/snapshot-101-copy-on-wri.../ Где там хоть слово про Btrfs?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (74), 06-Май-19, 21:46
	А где там не про Btrfs? Я к тому, что выше Вы сделали вброс: > Ну хватит чушь-то нести, иксперты и так же без каких-либо аргументов или пояснений
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Fracta1L (ok), 07-Май-19, 06:38
	Неплохо ты порвался
	Ответить \| Правка \| Наверх \| Cообщить модератору


	104. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (-), 07-Май-19, 11:21
	Голословное утверждение
	Ответить \| Правка \| К родителю #86 \| Наверх \| Cообщить модератору


	91. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Ktoto (?), 07-Май-19, 09:30
	Ты чукча писатель, не читатель ? и похоже не думатель ...
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	107. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Fracta1L (ok), 07-Май-19, 11:49
	Там ни одним словом Btrfs не упоминается. Тебе его голоса из розетки нашептали?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	112. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Ktoto (?), 07-Май-19, 14:32
	Там сравнивается архитектура copy-on-write на которой построен BTRFS и redirect-on-write на которой построен ZFS. Таки ты писатель, а не читатель!
	Ответить \| Правка \| К родителю #107 \| Наверх \| Cообщить модератору


	103. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (-), 07-Май-19, 11:20
	Пока вижу только нотки истерики. Но они не истина в последней инстанции. Конструктивная мы не дождемся?
	Ответить \| Правка \| К родителю #57 \| Наверх \| Cообщить модератору


	56. "Релиз ядра Linux 5.1"	–1 +/–
	Сообщение от Fracta1L (ok), 06-Май-19, 16:24
	>Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и лучше работает, чем на ext4/zfs Отменный доширак на уши.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	70. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (70), 06-Май-19, 20:32
	У ZFS 2 вида кеша, часто используемые блоки вымываются хуже. На некоторых особых сценариях работы базы это может выстрелить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Релиз ядра Linux 5.1"	+2 +/–
	Сообщение от Аноним (70), 06-Май-19, 20:30
	Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного блока базой с диска поднимается информация из 4-х и 3 из них засоряют кеш. Пишется тоже много лишнего... Блок ФС должен быть равен рабочему блоку базы (8к). Кеш данных нужно выключать. Можно врубить L2ARС, возможно от него будет прок, от журнала на SSD явно прок будет, но ARC для ФС с данным базы нужно отключить и дать больше шареной памяти, постгря сама придумает, что с этой памятью делать. Ну если это сервер БД, а не БД на домашнем сервере с ещё десятком сервисов... Это всё ИМХО конечно, но всё же...
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	71. "Релиз ядра Linux 5.1"	+/–
	Сообщение от xm (ok), 06-Май-19, 20:43
	> Блок ФС должен быть равен рабочему блоку базы (8к) Всё верно. А для MySQL 16Kb для данных InnoDB и 128Kb для журналов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	88. "Релиз ядра Linux 5.1"	+10 +/–
	Сообщение от Stax (ok), 07-Май-19, 08:13
	> Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного блока базой с диска поднимается информация из 4-х и 3 из них засоряют кеш Эээ нет. Я знаю методичку, в которой вы это прочли. Но в жизни оно не так. Я пробовал и 8к, конечно же. Но 32 или даже 64 лучше (по всем реальным бенчмаркам в моих ситуациях 64 еще лучше, но тут уж я испугался и "сконсервативничал"). Во всяком случае, для SSD это точно так. Во-первых, на засорение кэша в памяти - по фигу. В моих шаблонах, к примеру, 128 ГБ машины (где примерно 80 под ARC) достаточно для хорошо нагруженной базы на пару-тройку терабайт. Никаких эффектов нехватки кэша не наблюдается. Хотя для еще больших баз и сверхбольших нагрузок, вероятно, лучше еще памяти. Во-вторых критичное тут IO. Я писал, что база получает огромный прирост скорости от сжатия, т.к. получается за то же время вытянуть больше данных. Но на маленьких блоках сжатие перестает работать. Вот пример цифр как раз для постгри: https://www.2ndquadrant.com/en/blog/pg-phriday-postgres-zfs/ Коэффициент сжатия 1.71 при 8к блоках против 7.59 при 128к. Или можно так представить: тратя в 4.4 раза больше времени, мы прочитываем в 16 раз больше данных (временем разжатия можно пренебречь). Но нагрузки от БД по чтению не являются случайными! Даже в OLTP процент чисто случайных выборок, когда каждый следующий блок не имеет отношения к предыдущему не такой большой. А в других нагрузках так постоянно БД приходится считывать последовательные куски - таблиц или индексов. И это как бы правда, что при считывании истинно случайных блоков мы будем тупо тратить в несколько раз больше времени. Но каждый раз, когда требуются последовательные блоки, мы за то же время считываем в разы больше информации. Ну и в-третьих, помимо сжатия считать более крупный блок эффективнее, чем два мелких последовательно. А в базе последовательной нагрузки не так мало, как писал выше (даже если кажется, что это не так!). Но надо заметить, что recordsize в zfs это не фиксация, а ограничение сверху. Поэтому если база будет активно писать или изменять случайные 8K блоки (в противоположность последовательной записи), то эти измененные блоки будут сохранться по 8K, что бы там в recordsize не стояло. Ну и оверхед будет при изменениях. Поэтому эффект от регулярного pg_repack для переписывания таблиц и индексов для постгри на zfs даже больше, чем в других ситуациях (в целом-то это много когда улучшает производительность). Прямо видно, как уменьшаются размеры на диске и увеличивается коэффициент сжатия и производительность - пишет-то постгрес своими блоками, но zfs последовательные записи (даже в несколько потоков) агрегирует и пишет своим recordsize. Цифр по постгресу, показывающих это на практике в каком-нибудь pgbench я в сети сейчас не вижу, а вот по mysql вполне находятся (где ситуация похожая): https://charlesnagy.info/it/mysql/how-to-decrease-iops-when-...- 16k лучше, чем 8, а 32k еще лучше. В общем, те люди, которые писали ту методичку скорее всего не учитывали, что придут SSD, не оценивали эффект от сжатия и в целом не пробовали гонять ни реальную нагрузку, ни хотя бы pgbench в современных реалиях ) Потому что методичка с советом брать recordsize=8k для постгри родом где-то из 2012 или 13 года, с тех пор многими бездумно копировалась, да и вообще не факт что авторы реально проверяли это все для постгри, а не скопировали с оракала по аналогии (а там ситуация немного другая, т.к. во-первых он не MVCC, а во-вторых там свое кэширование, а не системное). > Кеш данных нужно выключать )) попробуйте как-нибудь на досуге, будет очень смешно. Сейчас не готов показать цифры, но по памяти как-то так: когда работают несколько очень тяжелых запросов, надолго прогружающих диски, с включенным кэшем имеем 20 МБ/с случайных чтений на диск (NVMe дисков тогда возможности поставить не было, а это где-то предел энтерпрайзных SATA SSD'шников типа DC 3700 под долговременной нагрузкой). Видно, как дискам плохо, задержки (await) немаленькие. Ставим primarycache=metadata. О! У дисков открывается второе дыхание, ввод-вывод становится более-менее последовательным, они фигачат под 120 МБ/с. Задержки уменьшаются, все счастливы. Кроме пользователей: запросы начинают выполняться в несколько раз дольше. Опаньки. С другой стороны, та база была реальный хардкор. На более приличных экземплярах переход на ZFS и эффект от умного ARC + сжатия обычно настолько делает все легче, что выключайте что угодно, все равно скорее всего будет лучше, чем было до zfs. > Можно врубить L2ARС В базах, где я вынужден был перейти на zfs этап L2ARC давно пройден, т.к. хотсет превышает разумный объем SSD под L2ARC, они давно all-SSD. Хотя на начальных этапах в некоторых из них это работало. Но когда база на много терабайт и это не разу ни холодные данные, все это постоянно читается и пишется, L2ARC не работает.
	Ответить \| Правка \| К родителю #69 \| Наверх \| Cообщить модератору