The OpenNET Project / Index page

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

Релиз ядра Linux 5.1

06.05.2019 08:48

После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 5.1. Среди наиболее заметных изменений: новый интерфейс для асинхронного ввода/вывода io_uring, возможность использования NVDIMM в качестве ОЗУ, поддержка в Nouveau разделяемой виртуальной памяти, поддержка масштабируемого мониторинга очень больших ФС через fanotify, возможность настройки уровней сжатия Zstd в Btrfs, новый обработчик cpuidle TEO, реализация системных вызовов для решения проблемы 2038 года, возможность загрузки с устройств device-mapper без initramfs, LSM-модуль SafeSetID, поддержка комбинированных live-патчей.

Основные новшества:

  • Дисковая подсистема, ввод/вывод и файловые системы
    • Реализован новый интерфейс для асинхронного ввода/вывода - io_uring, который примечателен поддержкой поллинга ввода/вывода и возможностью работы как с буферизацией, так и без буферизации. Напомним, что предлагаемый ранее механизм асинхронного ввода/вывода "aio" не поддерживал буферизированный ввод/вывод, мог работать только в режиме O_DIRECT (без буферизации и в обход кэша), имел проблемы с возникновением блокировок из-за ожидания доступности метаданных и демонстрировал большие накладные расходы из-за копирования данных в памяти.

      В рамках API io_uring разработчики попытались устранить недостатки старого интерфейса aio. По производительности io_uring очень близок к SPDK и существенно опережает libaio при работе с включенным поллингом. Для использования io_uring в конечных приложениях, работающих в пространстве пользователя, подготовлена библиотека liburing, предоставляющая высокоуровневую обвязку над интерфейсом ядра;

    • В механизм отслеживания событий в ФС fanotify() добавлена поддержка отслеживания ситуаций изменения суперблока и структуры dirent (события создания, удаления и перемещения каталогов). Представленные возможности помогают решить проблемы с масштабируемостью, возникающие при создании рекурсивных отслеживаний изменений в очень больших ФС при помощи механизма inotify (изменения dirent ранее можно было отследить только через inotify, но эффективность в условиях рекурсивного отслеживания больших вложенных каталогов оставляла желать лучшего). Теперь подобный мониторинг можно эффективно производить через fanotify;
    • В файловой системе Btrfs добавлена возможность настройки уровня сжатия для алгоритма zstd, который может рассматриваться как оптимальный компромисс, между быстрым но неэффективным lz4 и медленным но хорошо сжимающим xz. По аналогии с тем как раньше можно было устанавливать уровень сжатия при применении zlib для zstd добавлена поддержка опции монтирования "-o compress=zstd:level". При тестировании минимальный первый уровень обеспечил сжатие данных в 2.658 раз при скорости сжатия 438.47 MB/s, скорости распаковки 910.51 MB/s и потреблении памяти 780 KB, а максимальный 15 уровень - в 3.126 раз, но при скорости сжатия в 37.30 MB/s, распаковки 878.84 MB/s и потреблении памяти 2547 KB.

      Из других улучшений в Btrfs можно отметить добавление отложенного выполнения операций сканирования поддерева для снижения нагрузки и реализацию нового ioctl для управления отключением устройств;

    • Добавлена возможность загрузки с файловой системы, размещённой на устройстве device-mapper, без применения initramfs. Начиная с текущего выпуска ядра устройства device-mapper можно напрямую использовать в процессе загрузки, например, как раздел с корневой ФС. Настройка раздела осуществляется при помощи загрузочного параметра "dm-mod.create". Среди разрешённых для загрузки модулей device-mapper: "crypt", "delay", "linear", "snapshot-origin" и "verity";
    • В ориентированную на Flash-накопители файловую систему F2FS добавлен флаг F2FS_NOCOW_FL (checkpoint=disable), позволяющий отключить режим copy-on-write для заданного файла;
    • Из ядра удалена файловая система Exofs, представляющая собой вариант ext2, адаптированный для работы с хранилищами объектов OSD (Object-based Storage Device). Также удалена поддержка SCSI-протокола для подобных устройств хранения объектов;
    • В XFS реализован режим always_cow, при котором вместо замены данных в блоках по месту применяется модель COW (для изменений создаётся копия блока). Для включения режима можно использовать команду "echo 1 > /sys/fs/xfs/debug/always_cow";
    • В CIFS обеспечено кэширование данных FILE_ALL_INFORMATION, что позволяет выполнять вызовы подобные "stat /mountpoint" на основе данных в кэше без обращения к серверу по сети. Добавлена возможность отправки запросов SMB3 FSCTL к серверу из утилит в пространстве пользователя, например, из smbinfo;
    • В EXT4 добавлен новый атрибут, доступный через sysfs (/sys/fs/ext4/{disk}/journal_task). Атрибут может оказаться полезным для перемещения потока обработки журнала в cgroup или его трассировки при помощи ftrace, perf или blktrace;
    • В EXT2 добавлена поддержка системного вызова statx c реализацией более эффективного и функционального варианта stat(), возвращающего расширенную информацию о файле, включая время создания файла и специфичные для файловых систем флаги;
    • Внесены исправления, нацеленные на увеличение масштабируемости и производительности файловых систем, работающих через механизм FUSE;
  • Виртуализация и безопасность
    • В prctl() добавлена опция PR_SPEC_DISABLE_NOEXEC для управления спекулятивным выполнением инструкций для выбранного процесса. Новая опция позволяет выборочно управлять защитой от спекулятивного выполнения для процессов, которые потенциально могут быть атакованы при помощи атаки типа Spectre. В случае активации опции при запуске нового процесса выполняется очистка бита SSBD в структуре задач;
    • Реализован LSM-модуль SafeSetID, позволяющий системным сервисам безопасно управлять пользователями без повышения привилегий (CAP_SETUID) и без получения полномочий пользователя root. Назначение привилегий осуществляется через определение в securityfs правил на основе белого списка допустимых привязок (в форме "UID1:UID2");
    • Добавлены низкоуровневые изменения, необходимые для стековой организации загрузки модулей безопасности (возможность загрузки одного LSM-модуля поверх другого). Представлен параметр загрузки ядра "lsm", позволяющий управлять тем, какие модули загружаются и в каком порядке;
    • В подсистему аудита добавлена поддержка пространств имён файлов;
    • Расширены возможности GCC-плагина structleak, позволяющего блокировать потенциальные утечки содержимого памяти Обеспечена инициализация любых переменных, которые используются в коде через обращение по ссылке в стеке;
  • Сетевая подсистема
    • Для сокетов реализована новая опция "SO_BINDTOIFINDEX", похожая на "SO_BINDTODEVICE", но принимающая в качестве аргумента индексный номер сетевого интерфейса вместо имени интерфейса. Для IPv6 добавлена опция сокетов IPV6_ROUTER_ALERT_ISOLATE, позволяющая ограничить приём анонсов ротеров (RA) только собственным пространством имён сокета;
    • В стек mac80211 добавлена возможность назначения одному устройству нескольких BSSID (MAC-адресов). В рамках проекта по оптимизации производительности WiFi в стек mac80211 добавлен учёт распределения эфирного времени и возможность распределять эфирное время между несколькими станциями (при работе в режиме точки доступа выделение меньшего времени на передачу медленным беспроводным станциям, вместо равномерного распределения времени между всеми станциями);
    • В модуль cfg80211/nl80211 при работе в режиме точки доступа добавлена возможность выноса обработчика аутентификации в пространство пользователя (Authentication offload);
    • Добавлен механизм "devlink health", предоставляющий уведомления при возникновении проблем с сетевым интерфейсом. Кроме того, в devlink реализован API для получения информации об устройстве и добавлена команда "flash update" для обновления прошивок сетевого адаптера;
    • Для сетевых мостов добавлена поддержка протокола MLD (Multicast Router Discovery, RFC4286);
    • Обеспечена возможность применения режима TCP Fast Open вместе с операциями zerocopy (отправка сообщений в sendmsg с флагом MSG_ZEROCOPY);
    • Добавлен интерфейс для диагностики сокетов AF_XDP;
    • Во встроенную реализацию протокола TLS добавлена поддержка TLS 1.3, помимо ранее поддерживаемого TLS 1.2;
  • Память и системные сервисы
    • Реализована безопасная доставка сигналов, учитывающая возможность повторного использования PID. Например, при выполнении вызова kill ранее могла возникнуть ситуация, когда сразу после отправки сигнала целевой PID мог быть освобождён из-за завершения работы процесса и занят другим процессом, и в итоге сигнал передавался другому процессу. Для исключения подобных ситуаций добавлен новый системный вызов pidfd_send_signal, который использует файловые дескрипторы из /proc/pid для обеспечения стабильной привязки к процессу. Даже если PID будет повторно задействован во время обработки системного вызова, файловый дескриптор не изменится и его можно безопасно использовать для отправки сигнала процессу;
    • Добавлена возможность использования устройств постоянной памяти (persistent-memory, например NVDIMM) в качестве ОЗУ. До сих пор в ядре подобные устройства поддерживались в качестве устройств хранения, но теперь их можно также применять как дополнительную оперативную память. Возможность реализована в ответ на пожелания пользователей, готовых мириться с отставанием производительности и желающих использовать штатный API управления памятью ядра Linux вместо применения имеющихся систем распределения памяти в пространстве пользователя, работающих поверх mmap для dax-файла;
    • Добавлен новый обработчик простоя CPU (cpuidle, решает когда можно перевести CPU в глубокие режимы экономии энергии, чем глубже режим - тем большая экономия, но и больше времени требуется для выхода из режима) - TEO (Timer Events Oriented Governor). До сих пор предлагалось два обработчика cpuidle - "menu" и "ladder", отличающиеся эвристикой. В обработчике "menu" имеются известные проблемы с принятием эвристических решений, для устранения которых было решено подготовить новый обработчик. TEO позиционируется как альтернатива обработчику "menu", позволяющая добиться более высокой производительности с сохранением того же уровня энергопотребления. Активировать новый обработчик можно при помощи загрузочного параметра "cpuidle.governor=teo";
    • В рамках работы по устранению проблемы 2038 года, вызванной переполнением 32-разрядного типа time_t, в состав включены системные вызовы, предлагающие для 32-разрядных архитектур 64-разрядные счётчики времени . В итоге, 64-разрядную структуру time_t теперь можно применять на всех архитектурах. Аналогичные изменения также реализованы в сетевой подсистеме для опций timestamp сетевых сокетов;
    • В систему горячего наложения патчей на ядро (live patching) добавлена возможность "Atomic Replace" для атомарного применения серии изменений к одной функции. Указанная возможность позволяет распространять сводные патчи, охватывающие сразу несколько изменений, вместо достаточно сложного для сопровождения процесса поэтапного наложения live-патчей в строго определённом порядке. Если раньше каждое следующее изменение должно было отталкиваться от состояния функции после прошлого изменения, то теперь возможно распространение сразу нескольких изменений, привязанных к одному исходному состоянию (т.е. сопровождающие могут поддерживать один сводный патч относительно базового ядра вместо цепочки из зависящих друг от друга патчей);
    • Объявлена устаревшей поддержка формата исполняемых файлов a.out и удалён код для формирования core-файлов в формате a.out, который находится в заброшенном состоянии. Формат a.out давно не применяется на системах с Linux, а генерация файлов a.out уже давно не поддерживается современными инструментальными средствами в конфигурациях для Linux по умолчанию. Кроме того, загрузчик для a.out файлов может быть реализован целиком в пространстве пользователя;
    • В механизм верификации BPF-программ добавлена возможность определения и удаления неиспользуемого кода. Включены патчи с поддержкой spinlock для подсистемы BPF, предоставляющие дополнительные возможности по управлению паралелльным выполнением BPF-программ. Добавлена возможность добавления через BPF-программы дополнительных заголовков в инкапсулированные пакеты IP (IP/GRE, GUE, IPIP). В eBPF реализована новая инструкция jmp32 и поддержка типа "__int128". В утилиту bpftool добавлена команда для вывода списка параметров eBPF. На базе BPF реализован фреймворк Host Bandwidth Manager, позволяющий ограничивать исходящую пропускную способность через cgroups. Добавлена документация по подсистеме BPF;
    • В команду "perf diff" добавлены новые опции-фильтры "--time", "--cpu", "--pid" и "--tid";
    • Добавлена загрузочная опция "driver_async_probe" для указания списка драйверов, инициализация которых будет проводится в асинхронном режиме (позволяет ускорить процесс загрузки ядра);
    • Убрано устаревшее поведение OOM killer, в соответствии с которым предпочтение при принудительном завершении отдавалось дочерним процессам наиболее агрессивного процесса, а не самому агрессивному процессу;
    • Добавлен sysctl kernel/sched_energy_aware для отключения планирования задач с учётом оптимизации энергопотребления (по умолчанию подобный режим отключен для большинства платформ);
  • Оборудование
    • В драйвер Nouveau добавлена поддержка гетерогенного управления памятью, обеспечивающего возможность обращения CPU и GPU к общим синхронизированным областям памяти. Система разделяемой виртуальной памяти (SVM, shared virtual memory) реализована на базе подсистемы HMM (Heterogeneous memory management), позволяющей использовать устройства с собственными блоками управления памятью (MMU, memory management unit), которые могут получать доступ к основной памяти. В том числе при помощи HMM можно организовать совместное адресное пространство между GPU и CPU, в котором GPU может получить доступ к основной памяти процесса. Поддержка SVM пока включена только для GPU семейства Pascal, хотя поддержка обеспечена и для GPU Volta и Turing. Кроме того, в Nouveau добавлен новый ioctl для управления миграцией областей памяти процессов в память GPU;
    • В DRM-драйвере Intel для GPU Skylake и новее (gen9+) включён по умолчанию режим fastboot, исключающий лишние смены режимов во время загрузки. Добавлены новые идентификаторы устройств на базе микроархитектур Coffelake и Ice Lake. Для чипов Coffelake добавлена поддержка GVT (виртуализация GPU). Для виртуальных GPU реализована поддержка VFIO EDID. Для LCD панелей MIPI/DSI добавлена поддержка элементов ACPI/PMIC. Реализованы новые TV-режимы 1080p30/50/60 TV;
    • В драйвер amdgpu добавлена поддержка GPU Vega10/20 BACO. Реализованы средства управления питанием Vega 10/20 и таблицы управления кулером Vega 10. Добавлены новые PCI-идентификаторы устройств для GPU Picasso. Добавлен интерфейс управления планируемыми зависимостями для исключения взаимных блокировок;
    • Добавлен DRM/KMS-драйвер для ускорителей экранных операций ARM Komeda (Mali D71);
    • Добавлена поддержка экранных панелей Toppoly TPG110, Sitronix ST7701, PDA 91-00156-A0, LeMaker BL035-RGB-002 3.5 и Kingdisplay kd097d04;
    • Добавлена поддержка звуковых кодеков Rockchip RK3328, Cirrus Logic CS4341 и CS35L36, MediaTek MT6358, Qualcomm WCD9335 и Ingenic JZ4725B, а также звуковой платформы Mediatek MT8183;
    • Добавлена поддержка NAND-контроллеров Flash STMicroelectronics FMC2, Amlogic Meson;
    • Добавлена поддержка Habana Goya, ускорителей операций для нейронных сетей;
    • Добавлена поддержка гигабитных Ethernet-контроллеров NXP ENETC и беспроводных интерфейсов MediaTek MT7603E (PCIe) и MT76x8;
    • Добавлена поддержка новых ARM SoC: Socionext SC2000 (Milbeaut), Bitmain BM1880, Renesas RZ/A2M (R7S9210), Renesas RZ/G2E (r8a774c0), NXP i.MX8QuadXPlus, Mediatek MT7629;
    • Добавлена поддержка новых ARM плат и платформ: NVIDIA Shield TV (Darcy) на базе Tegra210, Bosch Guardian, Winterland IceBoard, Inspur on5263m5, Zodiac Digital Tapping Unit, Phicomm K3, X96 Max, FriendlyElec NanoPC-T4, NanoPi M4, Radxa ROCK Pi 4, Logic PD i.MX6QD, Y Soft IOTA Draco/Hydra/Ursa, Phytec phyCORE i.MX6 UltraLite, MYIR Tech MYD-LPC4357, Chameleon96, Oxalis Evalkit V100, Elgin RV1108 R, Si-Linux CAT874, Si-Linux EK874, Raspberry Pi Model 3 A+,

Одновременно Латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 5.1 - Linux-libre 5.1-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В новом выпуске отключена загрузка блобов в драйверах mt7603 и goya. Обновлён код чистки блобов в драйверах и подсистемах wilc1000, iwlwifi, soc-acpi-intel, brcmfmac, mwifiex, btmrvl, btmtk и touchscreen_dmi. Прекращена чистка блобов в загрузчике прошивок lantiq xrx200 из-за его удаления из ядра.

  1. Главная ссылка к новости (https://lkml.org/lkml/2019/5/5...)
  2. OpenNews: Релиз ядра Linux 5.0
  3. OpenNews: Релиз ядра Linux 4.20
  4. OpenNews: Релиз ядра Linux 4.19
  5. OpenNews: Релиз ядра Linux 4.18
  6. OpenNews: Релиз ядра Linux 4.17
Лицензия: CC-BY
Тип: Интересно / Программы
Ключевые слова: linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (112) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, EuPhobos (ok), 09:06, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –27 +/
    > возможность использования NVDIMM в качестве ОЗУ

    Хмм-хмм, интересненько, оно только с Nouveau наверное будет работать?

     
     
  • 2.2, немезидеЦ (?), 09:19, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    NVDIMM это совсем не технология NVidia.
    https://en.wikipedia.org/wiki/NVDIMM
     
  • 2.4, Аноним (4), 09:30, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мои инициалы NV.
    Я тоже принадлежу нвидии?
     
     
  • 3.6, Аноним (6), 09:55, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Получается так, Николай Владимирович. Все мы так понемногу...
     
  • 3.9, анон (?), 10:59, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Yes!
     
  • 2.35, Аноним (-), 13:06, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем ты написал это коммент? Твоя цель - какова?
     
     
  • 3.120, Аноним (120), 14:37, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у первопостера нет времени разбираться в вопросе, нужно поскорее что то ляпнуть.
     
  • 2.44, Аноним (44), 14:38, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    репрезентативный уровень икспертизы опеннета
     

  • 1.7, Аноним (7), 10:11, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Добавлена поддержка ускорителей для систем машинного обеспечения Habana AI;

    ЩИТО?

     
     
  • 2.12, Аноним (-), 11:12, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Надо было Kizuna Ai
     

  • 1.8, ффф (?), 10:54, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Во встроенную релизацию протокола TLS

    - зачем оно там? и зачем тогда опен/либра_ssl?

     
     
  • 2.11, Штирлиц (?), 11:09, 06/05/2019 Скрыто
  • –6 +/
     
     
  • 3.15, А (??), 11:23, 06/05/2019 Скрыто
  • +2 +/
     
     
  • 4.21, Аноним (21), 11:46, 06/05/2019 Скрыто
  • +/
     
     
  • 5.24, Аноним (24), 11:54, 06/05/2019 Скрыто
  • +6 +/
     
     
  • 6.81, Аноним (81), 23:30, 06/05/2019 Скрыто
  • +/
     
     
  • 7.83, Led (ok), 00:35, 07/05/2019 Скрыто
  • +7 +/
     
  • 2.17, zanswer CCNA RS and S (?), 11:36, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    «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.  

     
     
  • 3.37, КО (?), 13:21, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >Суть идеи в том, что

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

     
     
  • 4.46, Аноним (24), 15:06, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Поле Total Length в заголовке IP имеет размер, всего лишь, 16 бит, если что.
     
  • 4.55, Аноним (55), 16:22, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Голословное утверждение
     
  • 4.92, zanswer CCNA RS and S (?), 09:33, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вы ошибаетесь, когда думаете, что для ядра есть разница, какой размер имеют пере... текст свёрнут, показать
     
  • 2.52, Имя (?), 15:45, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    облегчить работу скомпрометированному ядру
     
     
  • 3.58, Аноним (55), 16:30, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Скомпрометированное ядро и так имеет доступ к памяти всех пользовательских процессов
     

  • 1.10, Аноним (10), 11:06, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > В XFS реализован режим always_cow, при котором вместо замены данных в блоках по месту применяется модель COW

    А что, так можно было??

    COW там только для данных или для метаданных тоже можно?

    > В файловой системе Btrfs добавлена возможность настройки уровня сжатия для алгоритма zstd

    несколько не по адресу, конечно, но лучше бы в zfs уже zstd добавили, пару лет уже висит https://github.com/zfsonlinux/zfs/issues/6247 и давным-давно патчи готовы, но нет, чем довести это до ума и получить zstd в рабочей и стабильной ФС, некие странные люди предпочитают ковырять далекий от продакшена btrfs.

     
     
  • 2.14, Fracta1L (ok), 11:22, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Классический пример zfs-фанбоя - возмущается, что люди предпочитают пилить Btrfs, а не полумёртвую zfs, примотанную к ядру сбоку скотчем.
     
     
  • 3.18, Аноним (10), 11:42, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    zfs я готов использовать в продакшене хоть сейчас в любой момент. Да, там есть нюансы (связанные как с тем, что это модуль вне ядра, так и прикрученным сбоку к ядру управлением памятью / spl), но тем не менее. Я точно знаю, какой прирост производительности я получу из-за ARC, какую надежность я получу из-за COW, контрольных сумм и прочего. В других задачах - какой объем я получу из-за raidz при отсутствии рисков типичного рейда. И так далее.
    А вот кто возьмет btrfs, над тем буду долго смеяться. Вы не видели, как она бьется с потерей данных пользователя? Я видел. Очень по-глупому она может умирать. И не спроста, повисев несколько лет в статусе экспериментальной в RHEL ее в итоге выкинули в статус прекращения поддержки. До лучших времен, которые не факт что наступят.

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

     
     
  • 4.19, Fracta1L (ok), 11:44, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Твои мысли и переживания на этот счёт крайне важны, я думаю что ты должен их написать в письме разработчикам ядра, чтобы они перестали заниматься Btrfs и засели за ZFS.
     
     
  • 5.31, Аноним (31), 12:40, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Btrfs лучше работает с зоопарком дисков. Разные размеры, добавление по одному, можно даже убрать диск и не заменять. В датацентрах это не нужно, а дома нужно.
     
     
  • 6.40, Stax (ok), 14:05, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А можно подробнее Я так понимаю, полноценного и рекомендованного к использовани... текст свёрнут, показать
     
     
  • 7.53, Имя (?), 15:53, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >диска меньшего размера

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

    >Большего размера, кстати, без проблем можно.

    с проблемами, место пропадает

     
     
  • 8.68, Аноним (10), 20:27, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ё-мае, ну zfs не идиоты же писали, в самом деле Там заложено небольшое но дост... текст свёрнут, показать
     
  • 7.98, нах (?), 10:53, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так понимаю, полноценного и рекомендованного к использованию аналога raid-z/2/3 в btrfs нет.

    есть, но он не работает ;-)

    к тому же там, по беглому погляду, write hole, как в "лучших" домах, zfs даже на raidz3 будет быстрее.

    а для дома я бы ни на той, ни на другой не рисковал ползучими апгрейдами дисков - учитывая, как оно все работает, единственно-правильный апгрейд - zfs send на новую пару или новый raidz. Можно изначально degraded - на первых порах старая поработает архивом.

     
  • 4.27, Аноним (-), 12:03, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Она не нужна никому не из-за плохой стабильности, а потому что это фс для сверх быстрых снепшотов, которые реализованы в угоду общей производительности. Снепшоты, разумеется, нужны не всем. Базу на ней не покрутишь, и систему ставить тоже никто не будет. А вот для файлопомойки она самое то. Проще говоря, у нее просто узкая специализация.
     
     
  • 5.41, Stax (ok), 14:16, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Угумс Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и л... текст свёрнут, показать
     
     
  • 6.45, Ktoto (?), 14:40, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    "Классический пример zfs-фанбоя" @Anonym
     
  • 6.50, Аноним (-), 15:28, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На сколько мне известно, в ZFS реализация COW сильно отличается от BTRFS. Она не захлёбывается на виртуалках или бд, но при этом использует агрессивное кеширование в память. И памяти ей нужно много.
     
     
  • 7.54, Ktoto (?), 16:11, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в ZFS COW на уровне блоков, в brfs на уровне файлов. В каком подходе больше оверхеда, в каком то больше возможностей.
     
     
  • 8.57, Fracta1L (ok), 16:24, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну хватит чушь-то нести, иксперты... текст свёрнут, показать
     
     
  • 9.61, Аноним (-), 17:25, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну просвяти нас ... текст свёрнут, показать
     
     
  • 10.62, Ktoto (?), 18:06, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Архитектура ZFS https storagegaga wordpress com tag redirect-on-write сравне... текст свёрнут, показать
     
     
  • 11.64, Fracta1L (ok), 18:40, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Где там хоть слово про Btrfs ... текст свёрнут, показать
     
     
  • 12.74, Аноним (74), 21:46, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А где там не про Btrfs Я к тому, что выше Вы сделали вброс и так же без каких-... текст свёрнут, показать
     
     
  • 13.86, Fracta1L (ok), 06:38, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Неплохо ты порвался... текст свёрнут, показать
     
     
  • 14.104, Аноним (-), 11:21, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Голословное утверждение ... текст свёрнут, показать
     
  • 12.91, Ktoto (?), 09:30, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты чукча писатель, не читатель и похоже не думатель ... текст свёрнут, показать
     
     
  • 13.107, Fracta1L (ok), 11:49, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там ни одним словом Btrfs не упоминается Тебе его голоса из розетки нашептали ... текст свёрнут, показать
     
     
  • 14.112, Ktoto (?), 14:32, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там сравнивается архитектура copy-on-write на которой построен BTRFS и redirect-... текст свёрнут, показать
     
  • 9.103, Аноним (-), 11:20, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Пока вижу только нотки истерики Но они не истина в последней инстанции Констру... текст свёрнут, показать
     
  • 6.56, Fracta1L (ok), 16:24, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и лучше работает, чем на ext4/zfs

    Отменный доширак на уши.

     
     
  • 7.70, Аноним (70), 20:32, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У ZFS 2 вида кеша, часто используемые блоки вымываются хуже. На некоторых особых сценариях работы базы это может выстрелить.
     
  • 6.69, Аноним (70), 20:30, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного блока базой с диска поднимается информация из 4-х и 3 из них засоряют кеш. Пишется тоже много лишнего... Блок ФС должен быть равен рабочему блоку базы (8к). Кеш данных нужно выключать. Можно врубить L2ARС, возможно от него будет прок, от журнала на SSD явно прок будет, но ARC для ФС с данным базы нужно отключить и дать больше шареной памяти, постгря сама придумает, что с этой памятью делать. Ну если это сервер БД, а не БД на домашнем сервере с ещё десятком сервисов... Это всё ИМХО конечно, но всё же...
     
     
  • 7.71, xm (ok), 20:43, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Блок ФС должен быть равен рабочему блоку базы (8к)

    Всё верно. А для MySQL 16Kb для данных InnoDB и 128Kb для журналов.

     
  • 7.88, Stax (ok), 08:13, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > Нельзя использовать 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-running-mysql-on-z 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 не работает.

     
     
  • 8.96, нах (?), 10:42, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну хоть один понимает, что делает, а не методички безграмотные перепевает P S... текст свёрнут, показать
     
  • 4.63, livelace (?), 18:35, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поддержку. На днях умерла btrfs после нештатного выключения. Умерла полностью. Самое интересное, что данные на данном томе вообще не использовались в тот момент. ФС на сервере: ext4 под систему, xfs под openstack swift, zfs под виртуальные машины. Выжили все, кроме btrfs.
     
     
  • 5.97, нах (?), 10:47, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не надо выдавать ваше случайное везение за общее правило.
    И да, что такое "умерла полностью" - что говорит mount и что показывает check ? (про dump-tree лучше не буду, все равно не разберетесь)

     
     
  • 6.113, Ktoto (?), 14:35, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    сейчас он вспомнит что там использовался RAID 5/6 ... точнее не . не вспомнит :-)
     
     
  • 7.115, нах (?), 16:02, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    насколько я помню (давно уже не слышал новостей от пользователей подобного) - там не при выключении умирало, а прямо на ходу разваливалось. С panic и прилетами в том числе и по соседним fs ;-)

    так что, вероятнее всего - не использовался.

     
  • 4.95, нах (?), 10:38, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вы не видели, как она бьется с потерей данных пользователя? Я видел.

    вы не видели как zfs pool превращается в тыкву с kernel panic при попытке его импорта/отрытия уже импортированного, похоронив ВСЕ данные вообще?

    Я вас огорчу, но вы ничерта, похоже, не знаете о предмете своего фетишизирования.

    > Проблема btrfs в том, что так и не достигнув стабильности, она оказалась не нужна никому.

    проблема zfs в том, что потеряв сановского тимлида с большой дубиной, она оказалась "нужна" массе торопыжных обезьянков, пильщиков грантов, которые сломали все что можно и нельзя, под предлогом мелкого улучшизма, и не сделали ничего из того что действительно надо было сделать - под предлогом "а у сана такого нет!".

     
     
  • 5.100, Stax (ok), 11:01, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет В солярке оракловой или одной из открытых Или это в линуксе В целом я вид... текст свёрнут, показать
     
     
  • 6.105, нах (?), 11:29, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    и в линуксе, и в freebsd, результаты примерно одинаковые - и починить не получит... текст свёрнут, показать
     
  • 3.20, Аноним (20), 11:45, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ZFS головного мозга. Тяжелая болезнь между прочим.
     
  • 2.22, Аноним (24), 11:49, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Какое отношение имеют разработчики ядра к LinuxZFS ?
     

  • 1.13, InuYasha (?), 11:21, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    >>проблемы 2038 года

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

     
     
  • 2.16, Аноним (16), 11:33, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вообще-то 1 января 1970 года. Так и представляю, как в 70х (да хоть и в 80х) годах процессор использует 64х битные числа для хранения UNIX-time.
     
     
  • 3.26, InuYasha (?), 12:00, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А не обязательно. Достаточно структуры с двумя 32-битными числами, обрабатываемыми по необходимости. Проблема в том, что хотели unix time использовать "лишь" для часов, но - увы и ах! - оно влезло всюду. О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались. Верили, наверное, что выхлопные газы и ГМО не дадут им дожить до конца unix time, но вот уже не за горами :D
     
     
  • 4.33, Аноним (33), 12:57, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Проблема не в хранении, а в вычислении. Накладные расходы сильно возрастают.
     
     
  • 5.36, Аноним (16), 13:20, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И в хранении проблема. В те времена память исчислялась килобайтами.
     
  • 4.59, Аноним (55), 16:38, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Unix time это формат _кодирования_ времени, а не формат хранения.

    > О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались

    В unix time вполне можно закодировать дату падения Российской Империи, достаточно использовать отрицательные числа и например double для хранения.

     
     
  • 5.82, Аноним (82), 23:38, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    double -- это уже 8 байт, да и польза от плавающей точки тут сомнительная.
     
  • 4.93, Совершенно другой аноним (?), 10:05, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вряд-ли у Вас будут файлы созданные, модифицированные или имевшие последний доступ во времена падения Российской Империи. Кстати, а почему не Римской, а то и не Египетских и разных Вавилонских царств?
     
  • 2.90, Совершенно другой аноним (?), 09:30, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Умный Microsoft, например, думал, думал, и придумал: у них один из форматов хранения времени количество единиц по 100 наносекунд с 1 января 1601 года UTC в хранящееся 64-х разрядном числе. Просто у Microsoft был опыт того-же Unix и плюс к этому гораздо подросшие вычислительные способности и объёмы памяти - самые первые Unix были 16-ти разрядные, если не путаю, с максимальным количеством памяти 144К, а реальным, насколько я понимаю - 9К - как Вы думаете, в таких условиях можно было для хранения времени выделять 8 байт? Удивительно, что они вообще до 32-х битного времени догадались.
     
  • 2.99, нах (?), 10:56, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    "разумеется, никто не думает, что юникс будет использоваться так долго".
    Из книжки кого-то из основоположников, середина 80х.


     

  • 1.23, Аноним (-), 11:52, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Про LZO-RLE в zram ещё добавьте
     
     
  • 2.76, Michael Shigorin (ok), 22:08, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Под новостью есть ссылка "исправить". :)
     

  • 1.25, Аноним (25), 11:57, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А кто-нибудь знает, как обстоят дела с DisplayLink драйверами в ядре?
     
  • 1.28, Нанобот (ok), 12:04, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Реализована безопасная доставка сигналов, учитывающая возможность повторного использования PID

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

     
     
  • 2.72, Аноним (72), 20:58, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А почему не использовать в этом случае просто UUID для процессов?
     
     
  • 3.89, Нанобот (ok), 08:56, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А почему не использовать в этом случае просто UUID для процессов?

    по причине его отсутствия

     

  • 1.29, Аноним (29), 12:21, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Linux XP?
     
  • 1.30, Анимайзер (?), 12:32, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Добавлена возможность использования устройств постоянной памяти (persistent-memory, например NVDIMM) в качестве ОЗУ

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

     
     
  • 2.38, Ууаа (?), 13:25, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Единая, быстрая память (MRAM или аналоги) без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК,

    Это будет новым вызовом нам, храбрейшим и умнейшим сынам каменных джунглей!
    Но мы знаем, мы уверены, что приложим все свои великие силы, будем жертвовать сном и бананами, но сможем эффективно занять и эту память одним тяжелым веб-приложением аналога калькулятора на нативном, близком к железу Браузере!
    У-у-а, товарищи! У-у-а!

     
  • 2.39, КО (?), 13:35, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >К этому рано или поздно все и придут

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

     
  • 2.102, Аноним (102), 11:17, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А перегружаться как?
     
     
  • 3.121, Аноним (121), 03:35, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    memset((void *)0, 0, total_ram)
     

  • 1.32, Аноним (32), 12:46, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Добавлена возможность загрузки с файловой системы, размещённой на устройстве device-mapper, без применения initramfs.

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

     
     
  • 2.42, Аноним (42), 14:17, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется в 4.14 билась файловая система.
     
     
  • 3.49, Ordu (ok), 15:20, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Кажется в 4.14 билась файловая система.

    Это где она билась? В смысле, что за дистр?

     
  • 3.108, Аноним (32), 12:25, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется
    > в 4.14 билась файловая система.

    о каких патчах речь, если не секрет?

     
  • 2.43, Аноним (43), 14:36, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможность не использовать initramfs была давным-давно. Просто так решил вскукарекнуть?
     
     
  • 3.48, Аноним (24), 15:16, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить "vgchange -ay" откуда-нибудь, чтоб корень увидеть.
     
     
  • 4.109, Аноним (32), 12:30, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить
    > "vgchange -ay" откуда-нибудь, чтоб корень увидеть.

    Спасибо, Анон.

     

  • 1.47, Пряникё (?), 15:14, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хватит добавлять свистоперделок в btrfs. Там от того, что уже накреативили - не продохнуть
     
  • 1.60, Аноним (55), 16:55, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > pidfd_send_signal

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

     
  • 1.73, просто_дурак_айти_не_мое (?), 21:44, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уже откомпилировал работает отлично gentoo-sources-5.1.0 gcc-9.1
     
  • 1.75, DerRoteBaron (ok), 22:04, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С патчами dma-buf для KVMGT (GVT-G) ничего не слышно?
     
     
  • 2.87, Заря (?), 08:06, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это тоже вспомнил https://looking-glass.hostfission.com ( https://github.com/gnif/LookingGlass ) тоже про него молчат, RedHat вообще все побоку.
     

  • 1.77, Michael Shigorin (ok), 22:10, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > подготовлена библиотека liburing, предоставляющая
    > высокоуровневую обвязку над интерфейсом ядра

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

    PS: смотреть в .gear/, в корне лежит нетронутый апстримный (см. %changelog).

     
     
  • 2.78, anonymous (??), 22:45, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А вы, случайно, не знаете, где можно найти доки по этой библиотеке? Быстрый поиск в сети не помог, либо пару example-ов нашёл, вместо исчерпывающего описания как работать с этой штукой.

    https://lwn.net/Articles/776230/
    http://git.kernel.dk/cgit/liburing/tree/examples

    Например, что это за ноль в третьем аргументе? --
        http://git.kernel.dk/cgit/liburing/tree/examples/io_uring-test.c#n31

     
     
  • 3.84, KonstantinB (ok), 00:43, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ноль это io_uring_params.flags, см. io_uring.h

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

     
  • 3.85, KonstantinB (ok), 00:45, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Более-менее исчерпывающей доки я не нашел, все отправные точки перечислены в посте.

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

     
     
  • 4.94, anonymous (??), 10:32, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо)
     
  • 2.80, Аноним (80), 23:06, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проработанный?
    > 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?

     
     
  • 3.101, anonymous (??), 11:11, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для тех, кто в spec-файлах ничего не понимает (вроде меня), что тут не так?)
     
     
  • 4.106, нах (?), 11:30, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    devel для .so - явное не так, остальное чьи-то личные тараканы

     
     
  • 5.111, anonymous (??), 12:59, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ОК, ещё мне, конечно, не нравится (своей экстримальной опасностью) строка:
    [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT

    А в остальных приведённых строках что не так? [если не впадлу прокомментировать :)]

     
  • 4.114, Аноним (114), 15:25, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Для тех, кто в spec-файлах ничего не понимает (вроде меня), что тут не так?)

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

     
     
  • 5.117, toshische (ok), 12:27, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще, это очень странный спек для ALT. Потому, что в ALT этот устаревший мусор совершенно не нужен и уже очень давно. Если я правильно помню, то раньше, чем в upstream RPM.

    И нельзя сказать, чтоб rpm-4.13.0.1-alt6 был очень уж несовременным :-D

     
  • 3.110, Аноним (32), 12:34, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > WTF?
    > [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT

    I'm loving it!

     
  • 3.119, Michael Shigorin (ok), 13:24, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Проработанный?

    Да: http://git.altlinux.org/gears/l/liburing.git?p=liburing.git;a=blob;f=.gear/li

    Мне стоило сразу оговориться, что в корне лежит нетронутый апстримный (хотя это и очевидно из %changelog в нём), а проработанный -- в .gear/; спасибо за замечание, поправил #77.

    re #106: "сам обоснуй" (ц) netch@
    re #114: ещё один путает .so и .so.*, не?
    re #118: надеюсь, ответил и тебе :)

     
  • 2.118, toshische (ok), 12:29, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А зачем в этом "проработанном" спеке столько закатов солнца вручную?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

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