|
2.134, Аноним (-), 02:45, 27/06/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Товарищ Майор будет рад
А что оно ему дает? Экономию RAM? Это не только майорам нравится. В остальных случаях нельзя ли поподробнее чем это кому грозит?
> Танцуем танго и нижний брейк, но одновременно :))
А был бы у тебя хвост, смог бы и еще чего-нибудь заодно.
> Лет через 5 можно будет юзать
Да юзать то можно хоть сейчас. Но с их управлением девайсами толку с этого...
> Ждём видосики: рубимся в Doom на стойке из Cisco .
Это, типа, из их светодиодиков экран для дума собрать? Типа, как на здании в тетрис светом в комнатах играли? Ох, мсье знает толк...
> Wifi 6 уже все попробовали? :)
Тсс, не мешай ящеркам палиться. И попроси у них нормальные батарейки в следующий раз. И хрен с ним, с гигабитами через подпространство.
| |
|
1.10, Аноним (10), 13:17, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>Удалён SLOB (slab allocator), устаревший механизм распределения памяти slab, который был спроектирован для систем с небольшим объёмом памяти.
и чо типерь делать? вот как типерь быть? дальше быть на debian 10.0? а патом куда периходить?
| |
1.13, Ананий (?), 13:19, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Мне вот другое интересно с этой дедупликацией памяти.
1)Ну вот отдедуплицировали три блока. Получили 1.
2)Вносим в 2 блока изменение, а памяти на раздупликацию, внезапно нетути.
3)?
| |
|
|
3.131, пох. (?), 01:07, 27/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> OOM, убиваем что попало!
Все убитое - объявляем ненужно.
поправил, не благодари.
| |
|
4.142, Аноним (-), 06:27, 27/06/2023 [^] [^^] [^^^] [ответить] | –2 +/– | При том у тех кто не любит RTFM оно будет убиваться по рандому Более разумные с... большой текст свёрнут, показать | |
|
|
|
3.20, birdie (ok), 13:34, 26/06/2023 [^] [^^] [^^^] [ответить]
| –4 +/– |
SWAP - это худший костыль компьютерной индустрии и он должен умереть.
Впрочем, на моих компах и серверах (> 200, high-load, >100 запросов в секунду) он выключен. Полёт отличный!
В Линукс зачем-то hibernate = swap, но это безумие и, надеюсь, hibernate отделят. Впрочем, и hibernate с приходом SSD/NVMe потерял актуальность.
| |
|
4.22, Аноним (5), 13:40, 26/06/2023 [^] [^^] [^^^] [ответить]
| +17 +/– |
Ты просто залил проблему железом. Есть задачи где так просто не сделать. А своп это то что позволяло шевелится 95 шинды на компе с 4 мегами оперы.
| |
|
5.27, Аноним (23), 13:42, 26/06/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
осталось найти такой комп и задачи для 95ой шинды...
а так да...
| |
5.29, Аноним (29), 13:45, 26/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Своп это то что сегодня позволяет играть в компьютерные игры с хорошими текстурами и без видеокарты с 16гб видеопамяти. В процессе это незаметно, только подгрузки уровня подольше (иногда очень подольше, но сами уровни не лагают).
| |
|
6.98, Аноним (98), 19:22, 26/06/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Он всё правильно написал, своп — это костыль для решения проблемы нехватки ресурсов. Да и всё это разделение на кэш процессора, RAM и диск само по себе убогий костыль, существующий только из-за того, что читать/писать с/на ППЗУ с частотой CPU пока не научились. И эти костыли с нами надолго.
| |
|
7.106, Аноним (29), 20:17, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ну смотри, даже в играх требование файла подкачки или отказывается работать, независимо от того сколько у тебя памяти. Разработчики адекватно рассудили, что неиспользуемые ресурсы неплохо бы вытеснить из памяти. На практике своп решает такие вопросы как утечки памяти в видеодрайвере. Ты либо каждый день перезапускаешь систему, либо раз в год с включённым свопом.
| |
|
|
5.35, Аноним (35), 13:58, 26/06/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
А в мобильниках/embedded он тоже используется? Посмотрим как быстро от него нaкроется NAND/eMMC
| |
|
6.39, llolik (ok), 14:03, 26/06/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
> А в мобильниках/embedded он тоже используется?
Там zram же используется, вроде как. Что, в принципе, тоже swap, но только в RAM.
| |
|
|
8.62, Аноним (62), 16:07, 26/06/2023 [^] [^^] [^^^] [ответить] | +/– | зато у свопа поверх zram назначение такое же как и у свопа поверх любого другого... текст свёрнут, показать | |
|
|
6.49, Анони (?), 14:46, 26/06/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Так и работают эти ваши мобильники и ембеддед прям скажем так себе.
| |
6.54, Аноним (54), 15:05, 26/06/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Уж лет 15 SSD используются, а народ всё своп на HDD переносит.
| |
|
|
|
|
10.205, по (?), 17:35, 03/07/2023 [^] [^^] [^^^] [ответить] | +/– | купил на али 1тб за 2к руб, тупо под торренты, чтобы винты не шуршали, сдохнет д... текст свёрнут, показать | |
|
|
8.79, Аноним (79), 16:35, 26/06/2023 [^] [^^] [^^^] [ответить] | +/– | Пользуюсь Samsung 850 Pro на 240 гигов более 7 лет, не отключав подкачку , про... текст свёрнут, показать | |
|
9.80, Аноним (29), 16:43, 26/06/2023 [^] [^^] [^^^] [ответить] | +/– | А сколько запись У меня и без свопа 200 гигабайт за день в норме и они понятн... текст свёрнут, показать | |
|
|
|
|
13.211, Аноним (-), 22:07, 09/07/2023 [^] [^^] [^^^] [ответить] | +/– | Зато не наплевать как это пишется и своп в этом не особо удачная штука, много ме... большой текст свёрнут, показать | |
|
|
|
|
13.180, Аноним (180), 09:01, 28/06/2023 [^] [^^] [^^^] [ответить] | +/– | Wearout флеша - вероятностный процесс Блок может стать плохим на 10-м цикле Ил... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
4.43, Аноним (44), 14:23, 26/06/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
WMware WS хрен запустится без наличия своп-раздела.
Но у тебя все хорошо
| |
4.56, User (??), 15:26, 26/06/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Так давно уже отдельный раздел не нужен, можно в файл сбрасывать... ну, иногда. На некоторых дистрибутивах. На некоторые файловые системы. С некоторой комбинацией запущенного софта и установленного железа. С определенной вероятностью может даже сработать - у некоторых даже несколько раз подряд, но тут сам не видел и врать не буду.
В общем и правда - проще сказать, что "hibernate потерял актуальность".
| |
4.58, Аноним (58), 15:44, 26/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Чото хайлоуд обмельчал каеш, кхем кхем, безусловно колличество запросов не мерило их ценности, но больше ста запросов в сек разве что для каких то супер задач хайлоуд, даж для фин транзакций нихуайлоуд
| |
4.95, Легивон (?), 18:57, 26/06/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тебе 15 лет, да? Или откуда такой идеализм?
Допустим у тебя есть нагруженый кластер Ceph на 10 стоек. Пару стоек моргнуло и запустилось снова. Начался resync, который жрет тучу памяти. Что по твоему лучше? Потормозить но синхронизоваться? Или лавинообразно сдохнуть от ООМ?
Такой вариант развития событий с памятью был в инциденте с Ceph у DO. Печально известный "мы старались, но у нас не получилось, проект закрыт" Cloudmouse, тоже сдох из-за недостатка памяти. Но там (для честности) помимо прочего еще и неадекватность присутствовала.
| |
|
5.99, Аноним (98), 19:26, 26/06/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Что по твоему лучше?
По-моему надо было лучше планировать, вовремя закупать оборудование, настраивать OOM score, и другие кошерные вещи. Но если из вариантов только тормозить или умереть… Лучше умереть. Быстрее деньги на оборудование найдутся.
| |
|
6.105, Аноним (104), 20:02, 26/06/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Твой подход не верный.
Для примера реальный случай. Рендер в Blender на домашнем компьютере, который никогда для этого не использовался, да и был собран для другого. Память при рендере ушла в ноль, а далее был задействован swap. Работа выполнена, хоть и медленно. Раз в год и палка стреляет)
| |
|
|
4.129, Вася (??), 00:20, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
на десктопе очень неплохо работает zram. Тем более с нынешними процессорами и объемами памяти, когда тупо всякое ненужное у тебя пережимается и практически забываешь, что бывает oom
| |
4.157, Tron is Whistling (?), 09:20, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чо, >200 запросов в секунду - это уже у наших любителей локалхоста highload?
У меня пых >1000 запросов в секунду на маленькой виртуалке делает.
| |
|
|
2.25, Аноним (29), 13:41, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Кстати, uksm годная штука, рекомендую. Особенно заметно на жава аппликухах, которые в ~2 раза меньше жрут. Процессора обычно достаточно, а вот без кешей хуже живётся.
| |
|
3.59, Аноним (58), 15:46, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
для ksm над готовить всякие костыли вроде LD_PRELOAD оберток и прочего, изкаропки ток хипервизоры поддерживают
| |
|
4.66, Аноним (29), 16:11, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Uksm просто работает, периодически мержит одинаковые страницы фоном.
| |
|
5.123, Аноним (123), 23:36, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
UKSM уже никем довольно давно не поддерживается. Давно столкнулись с архитектурными проблемами, патч вызывал проблемы со стабильностью и с эффективностью тоже были вопросы.
| |
|
6.128, Аноним (29), 00:07, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Какие проблемы со стабильностью и эффективностью, например? Я где-то пару лет использовал повсюду где можно. Патч можно и самому обновлять под апдейты (на гитхабе только под необновлённые ядра).
| |
|
|
|
|
2.34, Аноним (34), 13:54, 26/06/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
ну это примерно как с аллокатором: он тебе указатель таки отдаст, но память будет выделяться только когда попытаешься записать туда что-нить (и тут может быть ООМ)
| |
|
3.161, Anon3 (?), 11:52, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Т.е. даже сейчас любой код, меняющий значение ячейки памяти (например X=5+3), может дать исключение ООМ? Это вообще в языках программирования нормально реализовано?
| |
|
4.178, Аноним (178), 08:45, 28/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
1) X=5+3 современный компилер скорее всего оформит как нечто типа mov r1, #8, посчитав еще в компилтайме.
2) При этом обращения в память скорее всего не будет вообще.
3) Если X далее не используется или это ни на что не влияет, то этого кода не будет вообще.
4) Если это было про возможность что array[10005000] = 10 упадет, вот тут уже возможны варианты. По дефолту в линухе оверкомит, а страницы памяти физически выделяются только когда начинают их реально использовать. И можно номинально заказать себе сильно больше формальной аллокации чем реально система могла обеспечить. Это не ведет к проблемам пока вы это все и сразу юзать не удумаете. Это отключаемо если так не нравится, это гарантирует семантику вещей типа malloc() yj неэффективно по использованию RAM.
| |
|
|
2.38, pavlinux (ok), 14:01, 26/06/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
> 3)?
Отдуплившаяся страница помечается как CoW, как кто-то полезет
в неё на ЗАПИСЬ, она раздупляется и становиться самостоятельной.
| |
2.60, Тот_ещё_аноним (ok), 15:46, 26/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> 3)?
Тоже самое, что и без дедупликации
Но сильно позже и с меньшими шансами, ибо память сэкономлена
| |
2.67, Мамкинтролль (?), 16:11, 26/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Корректнее так:
1) Ну вот запустили мы кучу приложух через snap-flatpak
2) Запустили кучу приложух на электроне
3) Чё, нет денег на оперативу?
| |
|
1.32, Аноним (32), 13:52, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> В системном вызове open() запрещено одновременное указание флагов O_DIRECTORY и O_CREAT, которое теперь будет приводить к выводу ошибки EINVAL.
*в тишине раздался кашель, сквозь который звучит что-то, напоминающее "we-never-break-userspace"*
| |
|
2.37, llolik (ok), 14:00, 26/06/2023 [^] [^^] [^^^] [ответить]
| +4 +/– |
Ну, юзерспейс и не сломан. Флаги на месте, код соберётся и будет работать. Единственное изменение, в данной комбинации флагов возвращается код с ошибкой, которую, теоретически, и так надо-бы было обрабатывать.
| |
|
3.48, Аноним (46), 14:46, 26/06/2023 [^] [^^] [^^^] [ответить]
| –9 +/– |
Вы правда думаете, что комментаторы с опеннета что-то пишут на сишечке или близко к ней? Тут же ржавый и гошланг правят бал. :)
| |
|
4.93, Аноним (93), 18:41, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Можно подумать, на rust и golang ошибки не надо обрабатывать.
Более того, там надо явно выразить желание НЕ обрабатывать :-)
| |
4.110, Прохожий (??), 21:17, 26/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Только на ней, увы, и пишут в подавляющем большинстве. На большее уже не способны.
| |
4.127, Аноним. (?), 23:53, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Судя по комментам, тут только на assembler пишут. Ну ладно... Изредка на C, но НИКАКИХ плюсов!
| |
|
|
2.41, pavlinux (ok), 14:12, 26/06/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Они хитрожoпo это обошли
man open
ERRORS
open(), openat(), and creat() can fail with the following errors:
. . .
EINVAL O_CREAT was specified in flags and the final component of the new file's pathname is invalid
. . .
| |
|
3.45, pavlinux (ok), 14:30, 26/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А что, что-то сломалось?
Они ломают философию UNIX - "Всё есть файл!"
По-хорошему надо было сделать редирект на mkdir(), а тот бы уж вернул ENOTDIR,
если будут операции невозможные с директориями.
| |
|
4.97, Ananimus (?), 19:16, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Какую философию?
> O_DIRECTORY
> If pathname is not a directory, cause the open to fail. This flag was added in Linux 2.1.126, to avoid denial-of-service problems
> if opendir(3) is called on a FIFO or tape device. | |
4.100, Аноним (98), 19:29, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
> сделать редирект на mkdir()
Ну и зачем там это связывание? Чтобы потом правка кода в mkdir() что-нибудь сломала, желательно втихую и с повреждением данных?
| |
|
|
|
1.50, mos87 (ok), 14:50, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
интересно, амуди когда-нибудь свой pstate доделает, что он уже по умолчанию будет?
| |
1.65, Аноним (65), 16:10, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Опеннет 20ХХ год. Релиз ядра Linux 20ХХ. Было принято решение сменить нумерацию ядра на год выпуска соответствующего релиза. Весь код ядра был переписан с устаревшего и небезопасного языка С на безопасный ***. Напомним, что лицензия запрещает его называть, поэтому советом разработчиков ядра на всеобщем голосовании было принято решение дать этому языку кодовое имя ***. За проголосовало 99% представителей, один воздержался.
| |
1.73, Kuromi (ok), 16:26, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"В файловой системе Ext4 упрощена огранизация записи журнала (data=journal). Внесены оптимизации, связанные с предварительным распределением inode, позволившие ускорить работу в системах, в которых выполняется большое число случайных операций записи. Операции чтения и записи страниц памяти переведены на использование фолиантов страниц памяти (page folios)."
А когда ожидается поддержка аттрибута "безопасное удаление", чтобы без shred обходиться? (сарказм)
| |
1.78, Анонин (?), 16:35, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
> удалена опция монтирования "noacsrules", которая была некорректно реализована.
ахаха, лучший багфикс эвер!
| |
|
2.103, Kuromi (ok), 19:54, 26/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тем что у ramfs фиксированный размер в памяти (сколько задали, не больше не меньше) и есть оверхед на форматирование.
| |
|
1.83, Хру (?), 17:05, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Неотключаемый selinux? А как же тогда гугловский Project Zero любым примитивом на запись его отключает? И почему с этим ничего не сделать?
| |
1.85, Аноним123 (?), 17:23, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кто понял про этот LAM_57 режим? Могу ли я эти "лишние" биты использовать в своём user-space приложении например чтобы узнать, что помять не попорчена?
| |
1.89, Аноним (89), 18:17, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>Добавлена поддержка предоставляемого в процессорах Intel режима LAM_U57 (Linear Address Masking), позволяющего использовать часть битов 64-разрядных указателей (c 57 по 62 биты) для хранения не связанных с адресацией метаданных.
Ага. А потом "прекращена поддержка процессоров без LAM". Новые процессоры (а с ними и компьютеры целиком) себя сами не купят. Подобные вредительские инициативы нв корню рубить надо.
| |
|
2.94, Аноним (54), 18:42, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Фигасе далеко идущие выводы. Что там в ядре до сих пор поддерживается? i686?
| |
|
3.132, Аноним (132), 02:39, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
1. не в ядре, а в прикладном софте. хотят хранить в указателях доп. инфу - могут использовать структуры struct fat_pointer {void * ptr; uint8_t bullshit[as_much_as_needed];}; и проверять их x86-кодом.
2. до ядра это тоже доберётся. i486 же дропнули. good riddance, как Линус сказал.
| |
|
4.209, Аноним (209), 07:07, 09/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Самое смешное, что стоны про то, что дропнули i486 раздаются от тех, кто в силу возраста или нищеты в 90ых не застал i486 вообще
А те кто застал совершенно плевать хотели на то, что дропнули процессоры, которые были 25 лет назад, ведь эти процессоры давно на помойке
| |
|
|
|
1.91, Аноним (91), 18:40, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> slab SLAB
Насколько сейчас актуальны параметры командной строки ядра 'slab_nomerge' и 'slub_debug=FZ'?
| |
1.101, Аноним (-), 19:47, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.4 - Linux-libre 6.4-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем
Приятно видеть как наши товарищи из Латинской Америки сохраняют революционную сознательность.
| |
1.108, Атон (?), 20:56, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
> Добавлена поддержка предоставляемого в процессорах Intel режима LAM_U57 (Linear Address Masking), позволяющего использовать часть битов 64-разрядных указателей (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,
1) "640кб хватит всем"
2) хак завязанный на особенности реализации и поведения железа.
3) Дремучее legacy родилось на наших глазах.
| |
|
2.119, Аноним (119), 22:33, 26/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
>> (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,
> 1) "640кб хватит всем"
С одной стороны да, но 2^57 = 144 петабайта, если я не ошибся. Ограничения в 144 петабайт ОЗУ, при том, что в микроэлектронике мы уже уперлись в серьезные ограничения по размеру элементов, их соединений и, соответственно, их плотности упаковки и теплоотдачи, наверное лет на двадцать хватит минимум. Разве что изобретут что-то революционное, принципиально отличное от существующих технологий.
| |
|
|
4.133, Аноним (132), 02:40, 27/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Intel бы с радостью и на год каку зарыла. Новые камни сами собой не купятся.
| |
|
3.156, Атон (?), 08:59, 27/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,
>> 1) "640кб хватит всем"
> С одной стороны да, но 2^57 = 144 петабайта, если я не
> ошибся. Ограничения в 144 петабайт ОЗУ,
не "ОЗУ", а в аппаратной адресации. Это большая разница.
Мало тебе MemoryHole 640кб-1Mb, 15-16M, теперь и это добавили.
> при том, что в микроэлектронике
> мы уже уперлись в серьезные ограничения по размеру элементов, их соединений
> и, соответственно, их плотности упаковки и теплоотдачи, наверное лет на двадцать
> хватит минимум. Разве что изобретут что-то революционное, принципиально отличное от существующих
> технологий.
https://i.pinimg.com/originals/d1/f1/db/d1f1db3ec965a65f5c1644bbc0e74c95.jpg
| |
|
4.173, Аноним (119), 02:27, 28/06/2023 [^] [^^] [^^^] [ответить] | +/– | Ты хочешь сказать, что при 144-петабайтной адресации надо учитывать объем легаси... большой текст свёрнут, показать | |
|
5.191, Атон (?), 17:30, 28/06/2023 [^] [^^] [^^^] [ответить] | +/– | я прямо говорю что при любой адресации, любая дыра это не есть хорошо сколько... большой текст свёрнут, показать | |
|
6.200, Аноним (199), 13:40, 01/07/2023 [^] [^^] [^^^] [ответить] | +/– | Ну, поставить атрибуты в MMU и дело с концом Он эксепшн кинет, какое ему дело ... большой текст свёрнут, показать | |
|
|
|
|
|
1.109, Аноним (109), 21:12, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В последнее время nvme под систему хватает с избытком, поэтому и swap = 2x ram и 30% не размечаю. И выполняю заветы олдов, без понимания. И комментарии как то ясности не добавили. Есть новый завет?
| |
|
2.151, n00by (ok), 07:04, 27/06/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если используете гибернацию, размер подкачки желателен не меньше ОЗУ (хотя нередко достаточно столько, сколько ОЗУ занято). Если не используете, посмотрите, сколько в подкачке по максимуму бывает, из этого исходите. Если вдруг сильно понадобится подкачка, на популярных ФС её можно добавить, создав ещё файл. Про резерв 30% не знаю, что и сказать - производитель и без этого предусмотрел резерв. Экспертами платят торговцы железом, так что надо стимулировать спрос.
| |
2.166, Чукча (?), 17:40, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Однажды изучив технологию ssd, всю жизнь имели бы на 30% больше дискового пространства.
| |
|
1.114, YetAnotherOnanym (ok), 22:07, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> возможность создания работающих на уровне ядра обработчиков (kernel worker) из процессов в пространстве пользователя. (...) Реализация оптимизирована для совместного использования с io_uring.
Раздолье-то какое, раздолье!
| |
|
2.155, onanim (?), 08:59, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
> возможность создания работающих на уровне ядра обработчиков (kernel worker) из процессов в пространстве пользователя
астрологи объявили неделю LPE уязвимостей
| |
|
1.116, YetAnotherOnanym (ok), 22:16, 26/06/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> В интерфейсе асинхронного ввода/вывода io_uring появилась возможность одновременной прямой записи в файл в несколько потоков
А диск такой: "В очередь, с*кины дети, в очередь!".
Чем-то напоминает "менеджеры загрузок" эпохи диалапа, когда хомячки верили, что скачивание файла в несколько потоков позволит преодолеть лимит скорости модема.
| |
|
2.118, Аноним (54), 22:30, 26/06/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Походе, ни о временах диалапа, ни о нынешних накопителях вы ничего не знаете.
| |
|
3.159, YetAnotherOnanym (ok), 10:58, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Если Вас так задели мои слова, у вас есть шанс блеснуть познаниями по части менеджеров загрузки и современных накопителях.
| |
|
2.122, Аноним (122), 23:16, 26/06/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Позволяло если админ на той стороне ставил ограничение на скорость отдачи ниже лимита скорости модема. Проверено лично и неоднократно.
| |
|
3.144, фф (?), 06:34, 27/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
еще помогало, если линия не очень хорошая и часто возникали ошибки передачи. Пока один поток перезапрашивает кусок, файла линия простаивает, и второй в это время спокойно качает свою часть.
| |
3.162, Аноним (162), 12:43, 27/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так этож преодоление ограничений отдающего, а не ограничения скорости собственного модема.
| |
|
2.152, n00by (ok), 07:11, 27/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
В эпоху диалапа не каждый браузер знал про Accept-Ranges, и докачка (после обрыва соединения) работала в основном в менеджерах.
| |
2.165, Чукча (?), 17:37, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Вас уже обваляли в фикалиях по части диалапа. Бодбодрю жижу, в которой плескаетесь, со своей стороны:
для файла, занимающего страницы (по 4K), относящиеся к различным блокам страниц (~по 128 страниц) на диске, современный контроллер без сложностей обеспечит асинхронную параллельную запись.
| |
|
3.170, YetAnotherOnanym (ok), 19:37, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Здесь нашлось несколько индивидов, которые любят набрать в рот фекалий, чтобы плюнуть в сторону оппонента. На это забавно смотреть со стороны, особенно, когда к процессу присоединяются новые участники.
| |
|
4.189, Чукча (?), 14:49, 28/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
И не говорите. Ещё забавней наблюдать, как Вы в этих фикалиях плескаетесь, будучи не способным на контраргументацию, а лишь продолжая множить свои заблуждения.
| |
|
|
2.172, Tron is Whistling (?), 23:47, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
У скачивания файла в несколько потоков с быстрых серверов по диалапу было и есть вполне себе резонное объяснение.
К любимому мной 2G ныне всё настолько же применимо.
Дело кроется в регулярных потерях пакетов на сверхмедленном канале, а особенно - tcp ack, при приличном значении roundtrip latency.
Дальше объяснять не буду.
| |
|
|
2.163, Аноним (122), 15:56, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Я и говорю - молодцы. Должен же кто-то и само опенсорсие писать хотя бы ради прикола, а не 4 свободы и прочие лозунги.
| |
2.183, Аноним (183), 10:32, 28/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Не потрудились, а оплатили. И оплатили строго говоря тоже не корпорации, а их клиенты. Корпорация - посредник и паразит.
| |
|
|
2.164, Чукча (?), 17:23, 27/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если бы в самом деле хотели понять, то обратились бы к документации на kernel.org.
Как и ранее, для данных можно, для метаданных не рекомендуется. Для метаданных следует применять raid1, raid10, raid1c3, raid1c4. Для последних двух формат хранения ещё не зафиксирован.
| |
|
|
4.186, Чукча (?), 14:39, 28/06/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Может знаешь, а может и нет. Правда неизвестна, есть только твой вопрос в начале ветки и отписка на мой ответ.
| |
|
3.177, Аноним (-), 08:36, 28/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Для последних двух формат хранения ещё не зафиксирован.
Это с чего это не зафиксирован? Никто это уже ломать не собирается, вы чего. Из изменений V2 формата там скорее множественные экстентные деревья хотели и т.п. - сейчас в массово параллельной нагрузке с 1 деревом - lock contention случается, неоптимально по скорости, актуально для суперскоростных энтерпрайзных SSD.
| |
|
4.187, Чукча (?), 14:41, 28/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ломать может и не собираются, но формат raid1c3 и raid1c4 остаётся не зафиксированным.
| |
|
5.201, Аноним (199), 13:44, 01/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Ломать может и не собираются, но формат raid1c3 и raid1c4 остаётся не > зафиксированным.
Где это написано?
| |
|
|
|
2.169, DEF (?), 19:22, 27/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Давно можно. Метаданные хранишь на RAID1 (Подойдут 1TB диски, которые можно купить за копейки), а данные на RAID5/6. Все работает как часы.
| |
|
3.188, Чукча (?), 14:44, 28/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Для какого размера массива данных Вы предлагаете 1 Тбайт под метаданные?
| |
|
4.196, DEF (?), 15:01, 29/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
1 к 20-25 примерно. Зависит от выбранного алгоритма чексумм и от самих данных. Если очень много файлов маленького размера - они могут храниться в метаданных.
| |
|
5.197, Чукча (?), 23:34, 29/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
Вы дикость пишите. Для записи 1 Тбайт данных потребуется от силы 4 Гбайт метаданных, что есть 0.4%. Но никак ни 4-5% как утверждаете Вы.
| |
|
6.198, DEF (?), 01:12, 01/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чукча не читатель, чукча писатель?
Btrfs данные маленьких файлов может хранить в метаданных. Мануалы кури, чукча.
| |
|
|
4.202, Аноним (199), 13:48, 01/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Для какого размера массива данных Вы предлагаете 1 Тбайт под метаданные?
Вы явно не понимаете как RAID5/6 работает вообще - и тем более "file based" btrfs инкарнация в частности. Иначе не понятно откуда реверанс про терабайт под метаданные. Btrfs аллоцирует чанки данных и метаданных юнитами порядка нескольких гигз, блочные группы для данных или метаданных, в том или ином формате. Сколько ему будет надо под метаданные - столько и аллоцирует, если это место вообще было.
Откуда тут терабайт на метаданные берется в хоть каких-то факторах - кто ж его знает.
| |
|
|
2.176, Аноним (-), 08:34, 28/06/2023 [^] [^^] [^^^] [ответить]
| +/– |
RAID5 с метаданными в RAID1 - почему нет? У RAID6 write hole пока еще есть, до конца еще не заткнута. Другое дело что вон то сделано недавно, оттестированость пока еще скромная.
| |
|
1.182, Аноним (182), 10:01, 28/06/2023 [ответить] [﹢﹢﹢] [ · · · ] | –1 +/– | Так Linux превращают в ведро для помоев А патч для очистки Linux от ржавчины где... большой текст свёрнут, показать | |
|
2.203, Аноним (199), 13:51, 01/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> А патч для очистки Linux от ржавчины где?
А оно опциональное при сборке. И там вроде пока даже и очищать особо нечего.
| |
2.204, qux (ok), 20:09, 01/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Предполагаю что всё это затеяно для исключения GRUB. Другие загрузчики не поддерживают
> загрузку с шифрованных разделов и верификацией загрузки модулей, настроек, ядра и
> initrd.
Не поддерживают {загрузку с шифрованных + верификацию}, или только первое? Для корня в LUKS поддержки загрузчиком вроде никакой не нужно
| |
|
|