forum.opennet.ru - "Релиз ядра Linux 5.1" (115)

"Релиз ядра Linux 5.1"

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

"Релиз ядра Linux 5.1"	+/–
Сообщение от opennews (ok), 06-Май-19, 09:06
После двух месяцев разработки Линус Торвальдс представил (https://lkml.org/lkml/2019/5/5/278) релиз ядра Linux 5.1 (https://www.kernel.org). Среди наиболее заметных изменений в ядре 5.1: новый интерфейс для асинхронного ввода/вывода io_uring, возможность использования NVDIMM в качестве ОЗУ, поддержка в Nouveau разделяемой виртуальной памяти, поддержка масштабируемого мониторинга очень больших ФС через fanotify, возможность настройки уровней сжатия Zstd в Btrfs, новый обработчик cpuidle TEO, реализация системных вызовов для решения проблемы 2038 года, возможность загрузки с устройств device-mapper без initramfs, поддержка комбинированных live-патчей. Основные (https://kernelnewbies.org/Linux_5.1) новшества (https://lwn.net/Articles/783084): - Дисковая подсистема, ввод/вывод и файловые системы - Реализован новый интерфейс для асинхронного ввода/вывода - io_uring (http://kernel.dk/io_uring.pdf), который примечателен поддержкой поллинга ввода/вывода и возможностью работы как с буферизацией, так и без буферизации. Напомним, что предлагаемый ранее механизм асинхронного ввода/вывода "aio" не поддерживал буферизированный ввод/вывод, мог работать только в режиме O_DIRECT (без буферизации и в обход кэша) и имел проблемы с возникновением блокировок из-за ожидания доступности метаданных и накладными расходами из-за копирования данных в памяти. В рамках API io_uring разработчики попытались устранить недостатки старого интерфейса aio. По производительности (https://lore.kernel.org/linux-block/20190116175003.17880-1-a... io_uring очень близок к SPDK (https://spdk.io/) и существенно опережает libaio при работе с включенным поллингом. Для использования io_uring в конечных приложениях, работающих в пространстве пользователя, подготовлена библиотека liburing (http://git.kernel.dk/cgit/liburing/), предоставляющая высокоуровневую обвязку над интерфейсом ядра. - В механизм отслеживания событий в ФС fanotify() добавлена (https://github.com/amir73il/fsnotify-utils/wiki/Super-block-... поддержка отслеживания событий, приводящих к изменению суперблока и структуры dirent (https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout) (события создания, удаления и перемещения каталогов). Представленные возможности помогают решить проблемы с масштабируемостью, возникающие при создании рекурсивных отслеживаний изменений в очень больших ФС при помощи механизма inotify (изменения dirent ранее можно было отследить только через inotify, но эффективность в условиях рекурсивного отслеживания больших вложенных каталогов оставляла желать лучшего). Теперь подобный мониторинг можно эффективно производить через fanotify; - В файловой системе Btrfs добавлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... возможность настройки уровня сжатия для алгоритма zstd, который может рассматриваться как оптимальный компромисс, между быстрым но неэффективным lz4 и медленным но хорошо сжимающим xz. По аналогии с тем как раньше можно было устанавливать уровень сжатия при применении zlib для zstd добавлена поддержка опции монтирования "-o compress=zstd:level". При тестировании первый уровень обеспечил сжатие данных в 2.658 раз при скорость сжатия 438.47 MB/s, скорости распаковки 910.51 MB/s и потреблении памяти 780 MB, а 15 уровень - в 3.126 раз, но при скорости сжатия в 37.30 MB/s, распаковки 878.84 MB/s и потреблении памяти 2547 MB; - Добавлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... возможность загрузки с файловой системы, размещённой на устройстве device-mapper, без применения initramfs. Начиная с текущего выпуска ядра устройства device-mapper можно напрямую использовать в процессе загрузки, например, как раздел с корневой ФС. Настройка раздела осуществляется при помощи загрузочного параметра "dm-mod.create". Среди разрешённых для загрузки модулей device-mapper: "crypt", "delay", "linear", "snapshot-origin" и "verity"; - В ориентированную на Flash-накопители файловую систему F2FS добавлен флаг F2FS_NOCOW_FL, позволяющий отключить режим copy-on-write для заданного файла; - Из ядра удалена файловая система Exofs (https://www.opennet.ru/opennews/art.shtml?num=22084), представляющая собой вариант ext2, адаптированный для работы с хранилищами объектов OSD (Object-based Storage Device). Также удалена поддержка SCSI-протокола для подобных устройств хранения объектов; - Виртуализация и безопасность - В prctl() добавлена опция PR_SPEC_DISABLE_NOEXEC для управления спекулятивным выполнением инструкций для выбранного процесса. Новая опция позволяет выборочно отключать спекулятивное выполнение для процессов, которые потенциально могут быть атакованы при помощи атаки типа Spectre. Блокировка действует до первого вызова exec(); - Реализован LSM-модуль SafeSetID (https://www.kernel.org/doc/html/latest/admin-guide/LSM/SafeS... позволяющий системным сервисам безопасно управлять пользователями без повышения привилегий (CAP_SETUID) и без получения полномочий пользователя root. Назначение привилегий осуществляется через определение в securityfs правил на основе белого списка допустимых привязок (в форме "UID1:UID2"); - Добавлены низкоуровневые изменения, необходимые для стековой организации загрузки модулей безопасности (LSM). Представлен параметр загрузки ядра "lsm", позволяющий управлять тем, какие модули загружаются и в каком порядке; - В подсистему аудита добавлена поддержка пространств имён файлов; - Расширены (https://git.kernel.org/linus/81a56f6dcd20) возможности GCC-плагина structleak, позволяющего блокировать потенциальные утечки содержимого памяти Обеспечена инициализация любых переменных, которые используются в коде через обращение по ссылке в стеке; - Сетевая подсистема - Для сокетов реализована (https://git.kernel.org/linus/f5dd3d0c9638) новая опция "SO_BINDTOIFINDEX", похожая на "SO_BINDTODEVICE", но принимающая в качестве аргумента индексный номер сетевого интерфейса вместо имени интерфейса; - В стек mac80211 добавлена возможность назначения одному устройству нескольких BSSID (MAC-адресов). В рамках проекта по оптимизации производительности WiFi в стек mac80211 добавлен учёт распределения эфирного времени и возможность распределять эфирное время между несколькими станциями (при работе в режиме точки доступа выделение меньшего времени на передачу медленным беспроводным станциям, вместо равномерного распределния времени между всеми станциями); - Добавлен механизм "devlink health (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... ппредоставляющий уведомления при возникновении проблем с сетевым интерфейсом; - Память и системные сервисы - Реализована (https://git.kernel.org/torvalds/c/a9dce6679d736cb3d612af39ba... безопасная доставка сигналов, учитывающая возможность повторного использования PID. Например, при выполнении системного вызова kill ранее могла возникнуть ситуация, когда сразу после отправки сигнала целевой PID мог быть освобождён из-за завершения работы процесса и занят другим процессом, и в итоге сигнал применялся для другого процесса. Для исключения подобных ситуаций добавлен новый системный вызов pidfd_send_signal, который использует файловые дескрипторы из /proc/pid для обеспечения стабильной привязки к процессу. Даже если PID будет повторно задействован во время обработки системного вызова, файловый дескриптор не изменится и его можно безопасно использовать для отправки сигнала процессу; - Добавлена (https://lwn.net/Articles/777212/) возможность использования устройств постоянной памяти (persistent-memory, например NVDIMM (https://en.wikipedia.org/wiki/NVDIMM)) в качестве ОЗУ. До сих пор в ядре подобные устройства поддерживались в к... URL: https://lkml.org/lkml/2019/5/5/278 Новость: https://www.opennet.ru/opennews/art.shtml?num=50631
Ответить \| Правка \| Cообщить модератору

Оглавление

Хмм-хмм, интересненько, оно только с 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]

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

Сообщение от EuPhobos (ok), 06-Май-19, 09:06

> возможность использования NVDIMM в качестве ОЗУ
Хмм-хмм, интересненько, оно только с Nouveau наверное будет работать?

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

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

Сообщение от немезидеЦ (?), 06-Май-19, 09:19

NVDIMM это совсем не технология NVidia.
https://en.wikipedia.org/wiki/NVDIMM

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

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

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

Мои инициалы NV.
Я тоже принадлежу нвидии?

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

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

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

Получается так, Николай Владимирович. Все мы так понемногу...

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

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

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

Yes!

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

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

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

Зачем ты написал это коммент? Твоя цель - какова?

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

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

Сообщение от Аноним (120), 08-Май-19, 14:37

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

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

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

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

репрезентативный уровень икспертизы опеннета

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

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

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

>Добавлена поддержка ускорителей для систем машинного обеспечения Habana AI;
ЩИТО?

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

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

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

Надо было Kizuna Ai

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

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

Сообщение от ффф (?), 06-Май-19, 10:54

>Во встроенную релизацию протокола TLS
- зачем оно там? и зачем тогда опен/либра_ssl?

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

11. Скрыто модератором –5 +/–

Сообщение от Штирлиц (?), 06-Май-19, 11:09

Тов. майор попросил. А ты думал, гранты от корпораций Торвальдсу за красивые глаза прилетают?

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

15. Скрыто модератором +1 +/–

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

Специалист по красивым глазам детектед.

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

21. Скрыто модератором +/–

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

Окулист

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

24. Скрыто модератором +6 +/–

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

Маммолог

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

81. Скрыто модератором +/–

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

По красивым глазам - проктолог же!

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

83. Скрыто модератором +7 +/–

Сообщение от Led (ok), 07-Май-19, 00:35

MACолог же.

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

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

Сообщение от zanswer CCNA RS and S (?), 06-Май-19, 11:36

«The idea is for the kernel to handle the symmetric encryption and decryption, while leaving the handshake processing to user space. The feature uses the user-space API to the kernel's crypto subsystem, which is accessed via sockets created using the AF_ALG address family.»
https://lwn.net/Articles/666509/
Суть идеи в том, что таким образом выполняется offloading функций Record Layer TLS, он отвечает за передачу фактических данных, всё остальное остаётся в userspace, более того libressl и openssl взаимодействуют с KTLS.

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

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

Сообщение от КО (?), 06-Май-19, 13:21

>Суть идеи в том, что
теперь при атаке человек по средине, если кто-то додумается отправить в ответ 4T пакет, то упадет не Ваш любимый Appache/Nginx/Chrome/FF/нужное подставить, а сразу йадро.

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

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

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

Поле Total Length в заголовке IP имеет размер, всего лишь, 16 бит, если что.

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

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

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

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

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

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

Сообщение от zanswer CCNA RS and S (?), 07-Май-19, 09:33

Вы ошибаетесь, когда думаете, что для ядра есть разница, какой размер имеют передаваемые данные между приложениями.
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 содержит исчерпывающие требования к реализации TLS протокола и в частности Record Layer:
«5.  Record Protocol
The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result.  Received data is verified, decrypted, reassembled, and then delivered to higher-level clients.
TLS records are typed, which allows multiple higher-level protocols to be multiplexed over the same record layer. This document specifies four content types: handshake, application_data, alert, and change_cipher_spec.
~~~
5.1.  Record Layer
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules.
~~~
Application Data messages contain data that is opaque to TLS. Application Data messages are always protected.  Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure.  Application Data fragments MAY be split across multiple records or coalesced into a single record.
~~~
enum {
          invalid(0),
          change_cipher_spec(20),
          alert(21),
          handshake(22),
          application_data(23),
          (255)
      } ContentType;
struct {
          ContentType type;
          ProtocolVersion legacy_record_version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;
type:  The higher-level protocol used to process the enclosed fragment.
~~~
length:  The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert.
fragment:  The data being transmitted. This value is transparent and is treated as an independent block to be dealt with by the higher-level protocol specified by the type field.»
С точки зрения KTLS нет не какой разницы где начинается или заканчивается конкретное сообщение вышестоящего протокола, например HTTP. Ядро лишь разделает поток байт на блоки размером не превышающем 2^14, при превышении соединение разрывается; выполняет над ними криптографические операции и передаёт далее по стеку для отправки через сеть. Когда ядро получает данные по стеку, то выполняет над полученными данными криптографические операции, после чего объединяет полученные блоки в последовательный поток байт, снова не заботясь не о каких границах сообщений, вышестоящего протокола.
Поскольку в классическом случае TLS работает поверх TCP, то ему нет не какой нужды заботиться о порядке получения блоков или их количестве. С точки зрения TLS, всё блоки получены в том порядке и в том количестве, котором они были сформированными на передающей стороне. И теперь нужно лишь снова их преобразовать в последовательный поток байт, который прочитает наше приложение, например Apache.
P/S/ Если у кого-то есть замечания или указания на ошибки в изложенном, буду рад комментариям. :)

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

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

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

облегчить работу скомпрометированному ядру

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

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

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

Скомпрометированное ядро и так имеет доступ к памяти всех пользовательских процессов

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

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ообщить модератору

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

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

>>проблемы 2038 года
Никогда не понимал: при создании какого-то типа или структуры так трудно просчитать, какие числа она может хранить?? Очередной детский сад из 1980-ых, наверное... (-_-)

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

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

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

Вообще-то 1 января 1970 года. Так и представляю, как в 70х (да хоть и в 80х) годах процессор использует 64х битные числа для хранения UNIX-time.

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

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

Сообщение от InuYasha (?), 06-Май-19, 12:00

А не обязательно. Достаточно структуры с двумя 32-битными числами, обрабатываемыми по необходимости. Проблема в том, что хотели unix time использовать "лишь" для часов, но - увы и ах! - оно влезло всюду. О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались. Верили, наверное, что выхлопные газы и ГМО не дадут им дожить до конца unix time, но вот уже не за горами :D

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

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

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

Проблема не в хранении, а в вычислении. Накладные расходы сильно возрастают.

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

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

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

И в хранении проблема. В те времена память исчислялась килобайтами.

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

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

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

Unix time это формат _кодирования_ времени, а не формат хранения.
> О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались
В unix time вполне можно закодировать дату падения Российской Империи, достаточно использовать отрицательные числа и например double для хранения.

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

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

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

double -- это уже 8 байт, да и польза от плавающей точки тут сомнительная.

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

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

Сообщение от Совершенно другой аноним (?), 07-Май-19, 10:05

Вряд-ли у Вас будут файлы созданные, модифицированные или имевшие последний доступ во времена падения Российской Империи. Кстати, а почему не Римской, а то и не Египетских и разных Вавилонских царств?

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

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

Сообщение от Совершенно другой аноним (?), 07-Май-19, 09:30

Умный Microsoft, например, думал, думал, и придумал: у них один из форматов хранения времени количество единиц по 100 наносекунд с 1 января 1601 года UTC в хранящееся 64-х разрядном числе. Просто у Microsoft был опыт того-же Unix и плюс к этому гораздо подросшие вычислительные способности и объёмы памяти - самые первые Unix были 16-ти разрядные, если не путаю, с максимальным количеством памяти 144К, а реальным, насколько я понимаю - 9К - как Вы думаете, в таких условиях можно было для хранения времени выделять 8 байт? Удивительно, что они вообще до 32-х битного времени догадались.

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

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

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

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

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

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

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

Про LZO-RLE в zram ещё добавьте

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

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

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

Под новостью есть ссылка "исправить". :)

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

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

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

А кто-нибудь знает, как обстоят дела с DisplayLink драйверами в ядре?

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

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

Сообщение от Нанобот (ok), 06-Май-19, 12:04

> Реализована безопасная доставка сигналов, учитывающая возможность повторного использования PID
хорошо, конечно, давно нужно было сделать. мне бы эта функция пригодилась ещё где-то лет пятнадцать назад

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

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

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

А почему не использовать в этом случае просто UUID для процессов?

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

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

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

> А почему не использовать в этом случае просто UUID для процессов?
по причине его отсутствия

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

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

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

Linux XP?

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

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

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

> Добавлена возможность использования устройств постоянной памяти (persistent-memory, например NVDIMM) в качестве ОЗУ
Единая, быстрая память (MRAM или аналоги) без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК, а новые архитектуры потребуют и написания принципиально новых операционных систем. К этому рано или поздно все и придут. Выходит, Дмитрий Завалишин предвидел будущее и был всё-таки прав со своей Фантом ОС.

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

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

Сообщение от Ууаа (?), 06-Май-19, 13:25

> Единая, быстрая память (MRAM или аналоги) без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК,
Это будет новым вызовом нам, храбрейшим и умнейшим сынам каменных джунглей!
Но мы знаем, мы уверены, что приложим все свои великие силы, будем жертвовать сном и бананами, но сможем эффективно занять и эту память одним тяжелым веб-приложением аналога калькулятора на нативном, близком к железу Браузере!
У-у-а, товарищи! У-у-а!

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

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

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

>К этому рано или поздно все и придут
Или не придут. :)
А если быть точным от этого уже давно ушли. Ибо, пока, ограничения на ресурс и долговременное хранение очень сильно влияют на скорость чтения-записи и цену.

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

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

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

А перегружаться как?

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

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

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

memset((void *)0, 0, total_ram)

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

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

Сообщение от Ананас (?), 24-Май-19, 08:18

Переустановкой виндовс

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

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

Сообщение от uis (ok), 14-Дек-20, 00:00

>без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК, а новые архитектуры потребуют и написания принципиально новых операционных систем
Угу-угу. Никогда такого не было и вот опять. Яблодрочер что-ли? Те тоже любят заявлять, что придумали то, что было 100500 лет назад.
Фон Нейман негодует!

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

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

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

> Добавлена возможность загрузки с файловой системы, размещённой на устройстве device-mapper, без применения initramfs.
Ну наконец-то!!! Всегда удивлялся отсутствию этой сверхнеобходимой фичи. LVMу уж 100 лет в обед, а ядро без костылей могло грузиться только с обычных разделов. Компиляю 5.1 и выкидываю initramfs-tools!!!

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

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

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

Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется в 4.14 билась файловая система.

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

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

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

> Кажется в 4.14 билась файловая система.
Это где она билась? В смысле, что за дистр?

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

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

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

> Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется
> в 4.14 билась файловая система.
о каких патчах речь, если не секрет?

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

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

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

Возможность не использовать initramfs была давным-давно. Просто так решил вскукарекнуть?

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

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

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

Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить "vgchange -ay" откуда-нибудь, чтоб корень увидеть.

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

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

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

> Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить
> "vgchange -ay" откуда-нибудь, чтоб корень увидеть.
Спасибо, Анон.

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

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

Сообщение от Пряникё (?), 06-Май-19, 15:14

Хватит добавлять свистоперделок в btrfs. Там от того, что уже накреативили - не продохнуть

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

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

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

> pidfd_send_signal
Поскорее бы в bash добавили

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

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

Сообщение от просто_дурак_айти_не_мое (?), 06-Май-19, 21:44

Уже откомпилировал работает отлично gentoo-sources-5.1.0 gcc-9.1

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

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

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

С патчами dma-buf для KVMGT (GVT-G) ничего не слышно?

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

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

Сообщение от Заря (?), 07-Май-19, 08:06

Это тоже вспомнил https://looking-glass.hostfission.com ( https://github.com/gnif/LookingGlass ) тоже про него молчат, RedHat вообще все побоку.

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

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

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

> подготовлена библиотека liburing, предоставляющая
> высокоуровневую обвязку над интерфейсом ядра
Если кому понадобится чуть более проработанный спек, чем зимний пример в апстримном гите -- оно уже в сизифе: http://git.altlinux.org/tasks/archive/done/_223/229017/
PS: смотреть в .gear/, в корне лежит нетронутый апстримный (см. %changelog).

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

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

Сообщение от anonymous (??), 06-Май-19, 22:45

А вы, случайно, не знаете, где можно найти доки по этой библиотеке? Быстрый поиск в сети не помог, либо пару example-ов нашёл, вместо исчерпывающего описания как работать с этой штукой.
https://lwn.net/Articles/776230/
http://git.kernel.dk/cgit/liburing/tree/examples
Например, что это за ноль в третьем аргументе? --
    http://git.kernel.dk/cgit/liburing/tree/examples/io_uring-te...

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

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

Сообщение от KonstantinB (ok), 07-Май-19, 00:43

Ноль это io_uring_params.flags, см. io_uring.h
Я вот думаю, получится ли с этим сделать эффективную замену тред-пулу в nginx. Надо попробовать.

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

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

Сообщение от KonstantinB (ok), 07-Май-19, 00:45

Более-менее исчерпывающей доки я не нашел, все отправные точки перечислены в посте.
"Программа подробно задокументирована на языке C". Ну да не привыкать, со старым aio было еще хуже.

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

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

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

Спасибо)

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

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

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

Проработанный?
> Group:  System Environment/Libraries
> BuildRoot: %{_tmppath}/%{name}-root
>
> %clean
> [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
>
> %post -p /sbin/ldconfig
>
> %postun -p /sbin/ldconfig
Все уже лет десять как забыли про такую «проработку».
> %package devel
> Provides: liburing.so.1
WTF?

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

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

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

Для тех, кто в spec-файлах ничего не понимает (вроде меня), что тут не так?)

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

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

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

devel для .so - явное не так, остальное чьи-то личные тараканы

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

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

Сообщение от anonymous (??), 07-Май-19, 12:59

ОК, ещё мне, конечно, не нравится (своей экстримальной опасностью) строка:
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
А в остальных приведённых строках что не так? [если не впадлу прокомментировать :)]

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

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

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

> Для тех, кто в spec-файлах ничего не понимает (вроде меня), что тут не так?)
Тут не так то, что это всё устаревший мусор, не который при использовании актуальных версий rpm надлежит выкинуть. Но Альт и современный rpm — вещи несовместные.
А якобы предоставляемая devel-пакетом либа — какой-то бред, к тому же вредный. Я допускаю, конечно, что чего-то не знаю про Альт, но в любом другом дистрибутиве это недопустимая ошибка.

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

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

Сообщение от toshische (ok), 08-Май-19, 12:27

Вообще, это очень странный спек для ALT. Потому, что в ALT этот устаревший мусор совершенно не нужен и уже очень давно. Если я правильно помню, то раньше, чем в upstream RPM.
И нельзя сказать, чтоб rpm-4.13.0.1-alt6 был очень уж несовременным :-D

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

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

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

> WTF?
> [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
I'm loving it!

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

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

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

> Проработанный?
Да: http://git.altlinux.org/gears/l/liburing.git?p=liburing.git;...
Мне стоило сразу оговориться, что в корне лежит нетронутый апстримный (хотя это и очевидно из %changelog в нём), а проработанный -- в .gear/; спасибо за замечание, поправил #77.
re #106: "сам обоснуй" (ц) netch@
re #114: ещё один путает .so и .so.*, не?
re #118: надеюсь, ответил и тебе :)

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

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

Сообщение от аааа (?), 19-Июн-19, 22:41

bolgen os 2.0?

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

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

Сообщение от toshische (ok), 08-Май-19, 12:29

А зачем в этом "проработанном" спеке столько закатов солнца вручную?

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

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

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

Партнёры:

Хостинг:

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

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

1. "Релиз ядра Linux 5.1"	–30 +/–
Сообщение от EuPhobos (ok), 06-Май-19, 09:06
> возможность использования NVDIMM в качестве ОЗУ Хмм-хмм, интересненько, оно только с Nouveau наверное будет работать?
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Релиз ядра Linux 5.1"	+8 +/–
	Сообщение от немезидеЦ (?), 06-Май-19, 09:19
	NVDIMM это совсем не технология NVidia. https://en.wikipedia.org/wiki/NVDIMM
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Релиз ядра Linux 5.1"	+2 +/–
	Сообщение от Аноним (4), 06-Май-19, 09:30
	Мои инициалы NV. Я тоже принадлежу нвидии?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	6. "Релиз ядра Linux 5.1"	+10 +/–
	Сообщение от Аноним (6), 06-Май-19, 09:55
	Получается так, Николай Владимирович. Все мы так понемногу...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Релиз ядра Linux 5.1"	+2 +/–
	Сообщение от анон (?), 06-Май-19, 10:59
	Yes!
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	35. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (-), 06-Май-19, 13:06
	Зачем ты написал это коммент? Твоя цель - какова?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	120. "Релиз ядра Linux 5.1"	+2 +/–
	Сообщение от Аноним (120), 08-Май-19, 14:37
	у первопостера нет времени разбираться в вопросе, нужно поскорее что то ляпнуть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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

7. "Релиз ядра Linux 5.1"	+2 +/–
Сообщение от Аноним (7), 06-Май-19, 10:11
>Добавлена поддержка ускорителей для систем машинного обеспечения Habana AI; ЩИТО?
Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Релиз ядра Linux 5.1"	+10 +/–
	Сообщение от Аноним (-), 06-Май-19, 11:12
	Надо было Kizuna Ai
	Ответить \| Правка \| Наверх \| Cообщить модератору

8. "Релиз ядра Linux 5.1"	+2 +/–
Сообщение от ффф (?), 06-Май-19, 10:54
>Во встроенную релизацию протокола TLS - зачем оно там? и зачем тогда опен/либра_ssl?
Ответить \| Правка \| Наверх \| Cообщить модератору


	11. Скрыто модератором	–5 +/–
	Сообщение от Штирлиц (?), 06-Май-19, 11:09
	Тов. майор попросил. А ты думал, гранты от корпораций Торвальдсу за красивые глаза прилетают?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. Скрыто модератором	+1 +/–
	Сообщение от А (??), 06-Май-19, 11:23
	Специалист по красивым глазам детектед.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. Скрыто модератором	+/–
	Сообщение от Аноним (21), 06-Май-19, 11:46
	Окулист
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. Скрыто модератором	+6 +/–
	Сообщение от Аноним (24), 06-Май-19, 11:54
	Маммолог
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. Скрыто модератором	+/–
	Сообщение от Аноним (81), 06-Май-19, 23:30
	По красивым глазам - проктолог же!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. Скрыто модератором	+7 +/–
	Сообщение от Led (ok), 07-Май-19, 00:35
	MACолог же.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Релиз ядра Linux 5.1"	+5 +/–
	Сообщение от zanswer CCNA RS and S (?), 06-Май-19, 11:36
	«The idea is for the kernel to handle the symmetric encryption and decryption, while leaving the handshake processing to user space. The feature uses the user-space API to the kernel's crypto subsystem, which is accessed via sockets created using the AF_ALG address family.» https://lwn.net/Articles/666509/ Суть идеи в том, что таким образом выполняется offloading функций Record Layer TLS, он отвечает за передачу фактических данных, всё остальное остаётся в userspace, более того libressl и openssl взаимодействуют с KTLS.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	37. "Релиз ядра Linux 5.1"	–4 +/–
	Сообщение от КО (?), 06-Май-19, 13:21
	>Суть идеи в том, что теперь при атаке человек по средине, если кто-то додумается отправить в ответ 4T пакет, то упадет не Ваш любимый Appache/Nginx/Chrome/FF/нужное подставить, а сразу йадро.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Релиз ядра Linux 5.1"	+/–
	Сообщение от Аноним (24), 06-Май-19, 15:06
	Поле Total Length в заголовке IP имеет размер, всего лишь, 16 бит, если что.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	92. "Релиз ядра Linux 5.1"	+6 +/–
	Сообщение от zanswer CCNA RS and S (?), 07-Май-19, 09:33
	Вы ошибаетесь, когда думаете, что для ядра есть разница, какой размер имеют передаваемые данные между приложениями. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 содержит исчерпывающие требования к реализации TLS протокола и в частности Record Layer: «5. Record Protocol The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result. Received data is verified, decrypted, reassembled, and then delivered to higher-level clients. TLS records are typed, which allows multiple higher-level protocols to be multiplexed over the same record layer. This document specifies four content types: handshake, application_data, alert, and change_cipher_spec. ~~~ 5.1. Record Layer The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules. ~~~ Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. ~~~ enum { invalid(0), change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion legacy_record_version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; type: The higher-level protocol used to process the enclosed fragment. ~~~ length: The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. fragment: The data being transmitted. This value is transparent and is treated as an independent block to be dealt with by the higher-level protocol specified by the type field.» С точки зрения KTLS нет не какой разницы где начинается или заканчивается конкретное сообщение вышестоящего протокола, например HTTP. Ядро лишь разделает поток байт на блоки размером не превышающем 2^14, при превышении соединение разрывается; выполняет над ними криптографические операции и передаёт далее по стеку для отправки через сеть. Когда ядро получает данные по стеку, то выполняет над полученными данными криптографические операции, после чего объединяет полученные блоки в последовательный поток байт, снова не заботясь не о каких границах сообщений, вышестоящего протокола. Поскольку в классическом случае TLS работает поверх TCP, то ему нет не какой нужды заботиться о порядке получения блоков или их количестве. С точки зрения TLS, всё блоки получены в том порядке и в том количестве, котором они были сформированными на передающей стороне. И теперь нужно лишь снова их преобразовать в последовательный поток байт, который прочитает наше приложение, например Apache. P/S/ Если у кого-то есть замечания или указания на ошибки в изложенном, буду рад комментариям. :)
	Ответить \| Правка \| К родителю #37 \| Наверх \| Cообщить модератору


	52. "Релиз ядра Linux 5.1"	–3 +/–
	Сообщение от Имя (?), 06-Май-19, 15:45
	облегчить работу скомпрометированному ядру
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


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

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ообщить модератору