The OpenNET Project / Index page

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



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

Оглавление

Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в ФС, opennews (??), 04-Мрт-21, (0) [смотреть все]

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


49. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от Секрет (?), 05-Мрт-21, 00:10 
Не ошибается тот, кто ничего не делает! Наверное, что то умное пилят, раз всё сломали.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

58. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  –1 +/
Сообщение от oms (?), 05-Мрт-21, 00:20 
да потому что в сегодняшнем виде своп неюзабилен.
Ответить | Правка | Наверх | Cообщить модератору

148. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от z (??), 05-Мрт-21, 11:24 
Своп юзабелен, лагов нет. Но своп должен быть на zram, а ядро с патчем https://github.com/hakavlad/le9-patch
Ответить | Правка | Наверх | Cообщить модератору

167. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (170), 05-Мрт-21, 12:19 
tmpfs же более продвинутая фича чем zram zswap.
Ответить | Правка | Наверх | Cообщить модератору

196. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от foo (?), 05-Мрт-21, 14:37 
tmpfs не имеет отношения к свопу
Ответить | Правка | Наверх | Cообщить модератору

269. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 05-Мрт-21, 22:00 
> tmpfs же более продвинутая фича чем zram zswap.

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

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

273. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  –1 +/
Сообщение от Аноним (170), 05-Мрт-21, 22:31 
А в свопе разве не временные файлы всякие когда рам кончается? В tmpfs тоже ужимается между прочим.
Ответить | Правка | Наверх | Cообщить модератору

278. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от Аноним (-), 05-Мрт-21, 23:48 
Почитай что такое paging до того как умничать, чтоли? https://en.wikipedia.org/wiki/Memory_paging

Нет, это - не файлы, а страницы памяти. Кусочки памяти, типично 4096 байтов (4Кб) - как юнит управления памяти процессором. С своими атрибутами доступа и прочим.

Это немного пересекается в Linux с файловыми системами - порой достаточно плотно. Но таки своп хранит в себе именно страницы памяти. Которые в данный момент не используются, конечно. Это позволяет расчистить RAM для более востребованных кода и данных. В самом первом приближении это так: если прога долго (или никогда) не юзала какой-то код или данные, в какой-то момент ОС может выкинуть страницу из RAM в своп, а освободившуюся RAM отдать кому-то кому это нужнее, или поюзать под буфер дисков, для ускорения операций IO.

Ну а если прога все же возжелала те код или данные, при попытке туда обратиться... проц делает хардварный эксепшн, мол, невалидный доступ. Приходит ядро и пытается понять что ему делать дальше. Если оно знает где страницу взять (вынуть из свопа, декомпреснуть из zram, принести на голубях, ...) - страница оттуда достается, ядро мухлюет и возвращает программе проц в виде как будто исключений не было а программа никогда и не останавливалась. Пока ядро не вынет страницу, программа чисто технически не может быть продолжена, сие объясняет взвис программ при активном своплении. Ну а если страницы совсем не нашлось - упс - это левый доступ, нате-ка вам SIGSEGV, вы хотите что-то странное. И по дефолту должны за это умереть. Впрочем некоторые программы могут иметь иное мнение на этот счет и попробовать что-то иное. С пониманием того момента что состояние программы в такой ситуации уже врядли является корректным.

Tmpfs - вообще не об этом, он не занимается страницами. В него временные файлы предлагается складировать, в умеренном объеме. Выделяется, это, конечно, из страниц операитвной памяти. Но вот именно расчистить оперативку таким манером - не получится. В случае zram смысл в том что там СЖАТЫЙ блочный девайс из оперативы делается, на чем некий выигрыш. А tmpfs сжатие не умеет вроде, ну и смысл кидать страницы из RAM в RAM как есть? Чтобы потормозить с нулевым эффектом?

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

314. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от Аноним (207), 06-Мрт-21, 04:38 
Tmpfs емнип вытесняется в своп, zram нет. Поэтому, если у тебя tmpfs для временных файлов, и компиляция в нём, своп поможет очень значительно при недостатке памяти. А вот от сжатия профита не так много как хотелось бы, и есть всякие глюки вроде забитого ничем свопа (он не может при этом использоваться, и всё ещё хуже чем когда его нет вовсе). Может быть, дело ещё и в том, что официальная реализация алгоритмов значительно впереди относительно версий ядра.
Ответить | Правка | Наверх | Cообщить модератору

323. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 09:33 
> Tmpfs емнип вытесняется в своп, zram нет.

Вот про tmpfs я не помню с наскока. А выдавливать сжатый своп в своп было бы совсем уж маразмом и thrashing каким-то.

> Поэтому, если у тебя tmpfs для временных файлов, и компиляция в нём, своп
> поможет очень значительно при недостатке памяти.

Я сильно похож на системного идиота, чтобы сперв разогнать IO компилом в темпарь, а потом заякорить это счастье своплением? Вам никогда не приходило в бошку что дисковый буфер сам сделает при достатке оперативы некое подобие рамдиска?

Однако
1) без этой идиотской камасутры
2) без столь странных failure modes
3) самосбалансировавшись по скорости накопителя и доступной раме, при том довольно непохабно.

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

> А вот от сжатия профита не так много как хотелось бы,

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

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

У меня нет свопа на механике или SSD, поэтому и забиться он не может. А zram забивается медленно и постепенно cold pages которые типа-заюзаны, но как-то совсем уж dead code/data. А если окажется что punks not dead тогда они декомпреснутся с такой скоростью что я это не замечу. И даже в совсем уж OOM - ну, через 5-10 секунд просадки скорости в несколько раз oom killer прибьет offender'а. На свопе с механическим диском будет хруст головами цать минут, на SSD оно до дыр быренько протрет и такая эмуляция оперативы получается малость дороговата, проще нормальной RAM докупить чем SSD менять как лампочки.

> (он не может при этом использоваться, и всё ещё хуже чем
> когда его нет вовсе).

Меня видите ли в десктопной системе кроме bulk performance интересует еще low latency и user experience. И я вообще совсем не ок относительно тормозящих компьютеров. Для десктопа видите ли интерактивность не последнее дело.

> Может быть, дело ещё и в том, что официальная реализация алгоритмов значительно
> впереди относительно версий ядра.

Как минимум дефолты параметров свопа в 5.х сменили смысл. На, скажем так, нечто иное. Теперь можно в принципе попытаться делать иерархические свопы, это что-то типа IO cost и вроде можно так подогнать что сперва будет в ZRAM валиться а потом если не хватило то и в обычный. Но для себя я решил что эмулить патефонами RAM я принципиально не буду по соображениям латенси, а протереть SSD под системой до дыр в мои планы тоже не входит. И вообще, до того как подрыватся крутить все подряд в системной механике нехило б понять что оно делает и что хочется получить. А то может оказаться что майнтайнеры или ядершики были не тупее вас и совсем не факт что вы самый умный и улучшили что-то своим кручением, а не наоборот.

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

326. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (326), 06-Мрт-21, 10:09 
Да, я tmpfs использую. zram пробовал, но выгоды не получил.
Ответить | Правка | К родителю #314 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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