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

"Релиз ядра 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.me/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.me/opennews/art.shtml?num=50631
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

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

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

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

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

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

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

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

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

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

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

13. Сообщение от InuYasha (?), 06-Май-19, 11:21	–5 +/–
>>проблемы 2038 года Никогда не понимал: при создании какого-то типа или структуры так трудно просчитать, какие числа она может хранить?? Очередной детский сад из 1980-ых, наверное... (-_-)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #90, #99

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

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

16. Сообщение от Аноним (16), 06-Май-19, 11:33	+4 +/–
Вообще-то 1 января 1970 года. Так и представляю, как в 70х (да хоть и в 80х) годах процессор использует 64х битные числа для хранения UNIX-time.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #26

17. Сообщение от zanswer CCNA RS and S (?), 06-Май-19, 11:36	+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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #37

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

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

20. Сообщение от Аноним (20), 06-Май-19, 11:45	+2 +/–
ZFS головного мозга. Тяжелая болезнь между прочим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

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

22. Сообщение от Аноним (24), 06-Май-19, 11:49	+4 +/–
Какое отношение имеют разработчики ядра к LinuxZFS ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

23. Сообщение от Аноним (-), 06-Май-19, 11:52	+1 +/–
Про LZO-RLE в zram ещё добавьте
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #76

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

25. Сообщение от Аноним (25), 06-Май-19, 11:57	+/–
А кто-нибудь знает, как обстоят дела с DisplayLink драйверами в ядре?
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от InuYasha (?), 06-Май-19, 12:00	–2 +/–
А не обязательно. Достаточно структуры с двумя 32-битными числами, обрабатываемыми по необходимости. Проблема в том, что хотели unix time использовать "лишь" для часов, но - увы и ах! - оно влезло всюду. О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались. Верили, наверное, что выхлопные газы и ГМО не дадут им дожить до конца unix time, но вот уже не за горами :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #33, #59, #93

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

28. Сообщение от Нанобот (ok), 06-Май-19, 12:04	–2 +/–
> Реализована безопасная доставка сигналов, учитывающая возможность повторного использования PID хорошо, конечно, давно нужно было сделать. мне бы эта функция пригодилась ещё где-то лет пятнадцать назад
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #72

29. Сообщение от Аноним (29), 06-Май-19, 12:21	–3 +/–
Linux XP?
Ответить | Правка | Наверх | Cообщить модератору

30. Сообщение от Анимайзер (?), 06-Май-19, 12:32	+/–
> Добавлена возможность использования устройств постоянной памяти (persistent-memory, например NVDIMM) в качестве ОЗУ Единая, быстрая память (MRAM или аналоги) без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК, а новые архитектуры потребуют и написания принципиально новых операционных систем. К этому рано или поздно все и придут. Выходит, Дмитрий Завалишин предвидел будущее и был всё-таки прав со своей Фантом ОС.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #39, #102, #124

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

32. Сообщение от Аноним (32), 06-Май-19, 12:46	–1 +/–
> Добавлена возможность загрузки с файловой системы, размещённой на устройстве device-mapper, без применения initramfs. Ну наконец-то!!! Всегда удивлялся отсутствию этой сверхнеобходимой фичи. LVMу уж 100 лет в обед, а ядро без костылей могло грузиться только с обычных разделов. Компиляю 5.1 и выкидываю initramfs-tools!!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42, #43

33. Сообщение от Аноним (33), 06-Май-19, 12:57	+3 +/–
Проблема не в хранении, а в вычислении. Накладные расходы сильно возрастают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #36

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

36. Сообщение от Аноним (16), 06-Май-19, 13:20	+3 +/–
И в хранении проблема. В те времена память исчислялась килобайтами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

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

38. Сообщение от Ууаа (?), 06-Май-19, 13:25	+8 +/–
> Единая, быстрая память (MRAM или аналоги) без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК, Это будет новым вызовом нам, храбрейшим и умнейшим сынам каменных джунглей! Но мы знаем, мы уверены, что приложим все свои великие силы, будем жертвовать сном и бананами, но сможем эффективно занять и эту память одним тяжелым веб-приложением аналога калькулятора на нативном, близком к железу Браузере! У-у-а, товарищи! У-у-а!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

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

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

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

42. Сообщение от Аноним (42), 06-Май-19, 14:17	–5 +/–
Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется в 4.14 билась файловая система.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #49, #108

43. Сообщение от Аноним (43), 06-Май-19, 14:36	+/–
Возможность не использовать initramfs была давным-давно. Просто так решил вскукарекнуть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #48

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

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

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

47. Сообщение от Пряникё (?), 06-Май-19, 15:14	–1 +/–
Хватит добавлять свистоперделок в btrfs. Там от того, что уже накреативили - не продохнуть
Ответить | Правка | Наверх | Cообщить модератору

48. Сообщение от Аноним (24), 06-Май-19, 15:16	+/–
Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить "vgchange -ay" откуда-нибудь, чтоб корень увидеть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #109

49. Сообщение от Ordu (ok), 06-Май-19, 15:20	–1 +/–
> Кажется в 4.14 билась файловая система. Это где она билась? В смысле, что за дистр?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

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

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

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

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

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

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

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

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

59. Сообщение от Аноним (55), 06-Май-19, 16:38	+1 +/–
Unix time это формат _кодирования_ времени, а не формат хранения. > О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались В unix time вполне можно закодировать дату падения Российской Империи, достаточно использовать отрицательные числа и например double для хранения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #82

60. Сообщение от Аноним (55), 06-Май-19, 16:55	–1 +/–
> pidfd_send_signal Поскорее бы в bash добавили
Ответить | Правка | Наверх | Cообщить модератору

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

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

63. Сообщение от livelace (?), 06-Май-19, 18:35	+1 +/–
Поддержку. На днях умерла btrfs после нештатного выключения. Умерла полностью. Самое интересное, что данные на данном томе вообще не использовались в тот момент. ФС на сервере: ext4 под систему, xfs под openstack swift, zfs под виртуальные машины. Выжили все, кроме btrfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #97

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

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

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

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

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

72. Сообщение от Аноним (72), 06-Май-19, 20:58	+/–
А почему не использовать в этом случае просто UUID для процессов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #89

73. Сообщение от просто_дурак_айти_не_мое (?), 06-Май-19, 21:44	+/–
Уже откомпилировал работает отлично gentoo-sources-5.1.0 gcc-9.1
Ответить | Правка | Наверх | Cообщить модератору

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

75. Сообщение от DerRoteBaron (ok), 06-Май-19, 22:04	+/–
С патчами dma-buf для KVMGT (GVT-G) ничего не слышно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

76. Сообщение от Michael Shigorin (ok), 06-Май-19, 22:08	–1 +/–
Под новостью есть ссылка "исправить". :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

77. Сообщение от Michael Shigorin (ok), 06-Май-19, 22:10	+/–
> подготовлена библиотека liburing, предоставляющая > высокоуровневую обвязку над интерфейсом ядра Если кому понадобится чуть более проработанный спек, чем зимний пример в апстримном гите -- оно уже в сизифе: http://git.altlinux.org/tasks/archive/done/_223/229017/ PS: смотреть в .gear/, в корне лежит нетронутый апстримный (см. %changelog).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78, #80, #118

78. Сообщение от 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ообщить модератору
Родитель: #77 Ответы: #84, #85

80. Сообщение от Аноним (80), 06-Май-19, 23:06	+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?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #101, #110, #119

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

82. Сообщение от Аноним (82), 06-Май-19, 23:38	+/–
double -- это уже 8 байт, да и польза от плавающей точки тут сомнительная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

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

84. Сообщение от KonstantinB (ok), 07-Май-19, 00:43	+1 +/–
Ноль это io_uring_params.flags, см. io_uring.h Я вот думаю, получится ли с этим сделать эффективную замену тред-пулу в nginx. Надо попробовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

85. Сообщение от KonstantinB (ok), 07-Май-19, 00:45	+4 +/–
Более-менее исчерпывающей доки я не нашел, все отправные точки перечислены в посте. "Программа подробно задокументирована на языке C". Ну да не привыкать, со старым aio было еще хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #94

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

87. Сообщение от Заря (?), 07-Май-19, 08:06	+/–
Это тоже вспомнил https://looking-glass.hostfission.com ( https://github.com/gnif/LookingGlass ) тоже про него молчат, RedHat вообще все побоку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

88. Сообщение от Stax (ok), 07-Май-19, 08:13	+10 +/–
> Нельзя использовать 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 не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #96

89. Сообщение от Нанобот (ok), 07-Май-19, 08:56	+/–
> А почему не использовать в этом случае просто UUID для процессов? по причине его отсутствия
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

90. Сообщение от Совершенно другой аноним (?), 07-Май-19, 09:30	–1 +/–
Умный Microsoft, например, думал, думал, и придумал: у них один из форматов хранения времени количество единиц по 100 наносекунд с 1 января 1601 года UTC в хранящееся 64-х разрядном числе. Просто у Microsoft был опыт того-же Unix и плюс к этому гораздо подросшие вычислительные способности и объёмы памяти - самые первые Unix были 16-ти разрядные, если не путаю, с максимальным количеством памяти 144К, а реальным, насколько я понимаю - 9К - как Вы думаете, в таких условиях можно было для хранения времени выделять 8 байт? Удивительно, что они вообще до 32-х битного времени догадались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

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

92. Сообщение от zanswer CCNA RS and S (?), 07-Май-19, 09:33	+6 +/–
Вы ошибаетесь, когда думаете, что для ядра есть разница, какой размер имеют передаваемые данные между приложениями. 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/ Если у кого-то есть замечания или указания на ошибки в изложенном, буду рад комментариям. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

93. Сообщение от Совершенно другой аноним (?), 07-Май-19, 10:05	+/–
Вряд-ли у Вас будут файлы созданные, модифицированные или имевшие последний доступ во времена падения Российской Империи. Кстати, а почему не Римской, а то и не Египетских и разных Вавилонских царств?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

94. Сообщение от anonymous (??), 07-Май-19, 10:32	+/–
Спасибо)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

95. Сообщение от нах (?), 07-Май-19, 10:38	+1 +/–
> Вы не видели, как она бьется с потерей данных пользователя? Я видел. вы не видели как zfs pool превращается в тыкву с kernel panic при попытке его импорта/отрытия уже импортированного, похоронив ВСЕ данные вообще? Я вас огорчу, но вы ничерта, похоже, не знаете о предмете своего фетишизирования. > Проблема btrfs в том, что так и не достигнув стабильности, она оказалась не нужна никому. проблема zfs в том, что потеряв сановского тимлида с большой дубиной, она оказалась "нужна" массе торопыжных обезьянков, пильщиков грантов, которые сломали все что можно и нельзя, под предлогом мелкого улучшизма, и не сделали ничего из того что действительно надо было сделать - под предлогом "а у сана такого нет!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #100

96. Сообщение от нах (?), 07-Май-19, 10:42	+/–
ну хоть один понимает, что делает, а не методички (безграмотные) перепевает. P.S. те люди что их писали - еще и не отличали работу ARC от prefetch. А это _разные_ механизмы и управляются они по отдельности (нет, не надо его выключать, будет хуже) P.P.S. при включении сжатия у вас размер блока - переменный. Хотите фиксированных блоков "как в методичке" - отключайте сжатие. (разумеется, станет хуже ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

97. Сообщение от нах (?), 07-Май-19, 10:47	+1 +/–
не надо выдавать ваше случайное везение за общее правило. И да, что такое "умерла полностью" - что говорит mount и что показывает check ? (про dump-tree лучше не буду, все равно не разберетесь)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #113

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

99. Сообщение от нах (?), 07-Май-19, 10:56	+/–
"разумеется, никто не думает, что юникс будет использоваться так долго". Из книжки кого-то из основоположников, середина 80х.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

100. Сообщение от Stax (ok), 07-Май-19, 11:01	+/–
>> Вы не видели, как она бьется с потерей данных пользователя? Я видел. > вы не видели как zfs pool превращается в тыкву с kernel panic > при попытке его импорта/отрытия уже импортированного, похоронив ВСЕ данные вообще? Нет. В солярке оракловой или одной из открытых? Или это в линуксе? В целом я видел довольно экзотические проблемы с пулами, вызванные либо проблемами железа, либо странными манипуляциями с дисками при замене, но всегда решение находилось. А почему в тыкву? Если данные физически на диске не бьются (а с чего им биться, там же транзакции?) и можно попробовать еще раз? Ну а то, что в линуксе нет безопасного отладчика ядра типа mdb и оно чуть что так в панику - это как бы не вина zfs... > проблема zfs в том, что потеряв сановского тимлида с большой дубиной, она > оказалась "нужна" массе торопыжных обезьянков, пильщиков грантов, которые сломали все > что можно и нельзя, под предлогом мелкого улучшизма, и не сделали > ничего из того что действительно надо было сделать - под предлогом > "а у сана такого нет!". Хм. Ну кое-что полезное все-таки сделали. Большие блоки и шифрование (да-да, обе фичи появились в оракловой солярке после форка, но в открытую-то их пришлось заново добавлять) очень порадовали, discard для zvol (а этого и в оракловой нет! Правда, 11.4 я не щупал, но скорее всего тоже нет..) тоже полезен. LZ4 опять же раньше прикрутили. А что по-вашему "надо было сделать"? Block pointer rewrite, который лучшие сановские умы не смогли даже спроектировать толком? Это "торопыжных обезьянков, пильщиков грантов" не сделают никогда, думаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #105

101. Сообщение от anonymous (??), 07-Май-19, 11:11	+/–
Для тех, кто в spec-файлах ничего не понимает (вроде меня), что тут не так?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #106, #114

102. Сообщение от Аноним (102), 07-Май-19, 11:17	+/–
А перегружаться как?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #121, #122

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

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

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

106. Сообщение от нах (?), 07-Май-19, 11:30	+/–
devel для .so - явное не так, остальное чьи-то личные тараканы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #111

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

108. Сообщение от Аноним (32), 07-Май-19, 12:25	+/–
> Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется > в 4.14 билась файловая система. о каких патчах речь, если не секрет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

109. Сообщение от Аноним (32), 07-Май-19, 12:30	+/–
> Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить > "vgchange -ay" откуда-нибудь, чтоб корень увидеть. Спасибо, Анон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

110. Сообщение от Аноним (32), 07-Май-19, 12:34	+1 +/–
> WTF? > [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT I'm loving it!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

111. Сообщение от anonymous (??), 07-Май-19, 12:59	+/–
ОК, ещё мне, конечно, не нравится (своей экстримальной опасностью) строка: [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT А в остальных приведённых строках что не так? [если не впадлу прокомментировать :)]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

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

113. Сообщение от Ktoto (?), 07-Май-19, 14:35	+/–
сейчас он вспомнит что там использовался RAID 5/6 ... точнее не . не вспомнит :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #115

114. Сообщение от Аноним (114), 07-Май-19, 15:25	+/–
> Для тех, кто в spec-файлах ничего не понимает (вроде меня), что тут не так?) Тут не так то, что это всё устаревший мусор, не который при использовании актуальных версий rpm надлежит выкинуть. Но Альт и современный rpm — вещи несовместные. А якобы предоставляемая devel-пакетом либа — какой-то бред, к тому же вредный. Я допускаю, конечно, что чего-то не знаю про Альт, но в любом другом дистрибутиве это недопустимая ошибка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #117

115. Сообщение от нах (?), 07-Май-19, 16:02	+/–
насколько я помню (давно уже не слышал новостей от пользователей подобного) - там не при выключении умирало, а прямо на ходу разваливалось. С panic и прилетами в том числе и по соседним fs ;-) так что, вероятнее всего - не использовался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

117. Сообщение от toshische (ok), 08-Май-19, 12:27	+1 +/–
Вообще, это очень странный спек для ALT. Потому, что в ALT этот устаревший мусор совершенно не нужен и уже очень давно. Если я правильно помню, то раньше, чем в upstream RPM. И нельзя сказать, чтоб rpm-4.13.0.1-alt6 был очень уж несовременным :-D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

118. Сообщение от toshische (ok), 08-Май-19, 12:29	+1 +/–
А зачем в этом "проработанном" спеке столько закатов солнца вручную?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

119. Сообщение от 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: надеюсь, ответил и тебе :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #123

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

121. Сообщение от Аноним (121), 14-Май-19, 03:35	+/–
memset((void *)0, 0, total_ram)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

122. Сообщение от Ананас (?), 24-Май-19, 08:18	+/–
Переустановкой виндовс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

123. Сообщение от аааа (?), 19-Июн-19, 22:41	–1 +/–
bolgen os 2.0?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

124. Сообщение от uis (ok), 14-Дек-20, 00:00	+/–
>без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК, а новые архитектуры потребуют и написания принципиально новых операционных систем Угу-угу. Никогда такого не было и вот опять. Яблодрочер что-ли? Те тоже любят заявлять, что придумали то, что было 100500 лет назад. Фон Нейман негодует!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

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

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