Исходное сообщение
"Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..." Отправлено Аноним, 06-Мрт-21 00:57
> Потому что zram предназначен для эмуляции блочных устройств, что бы файлы располагать > в памяти и быстро с ними работать. Как сжатый своп он тоже очень прилично работает. Своп, внезапно, тоже блочное устройство. > место zswap, в результате чего последний недостаточно оттестирован. Унылая фигня. Потому что сжатие у него сделано мутно - и не отменяет траффика к диску. Это протирает SSD, дико тупит механикой, и в общем то не решает кардинально ни 1 проблемы по сравнению с обычным свопом. В то время как система с свопом только zram даже OOM отстреливает за секунды - и это вообще в целом low latency решение, что для десктопа актуально. Как угодно но время декомпрессии страницы RAM -> RAM не имеет ничего общего с IO к механическому диску и не протирает NVM-диск с ограниченым ресурсом, RAM не обижается даже на очень интенсивный своп. Но у опоздавщих включить мозг из обоснований своей правоты видимо только понты. > в результате чего последний недостаточно оттестирован. И хрен бы с ним. Пусть его тестируют те кому нравится хруст диском или протирание SSD. А с системой где своп только в zram этого всего - нет. Есть прозрачная компрессия кусочка оперативки, не более заданного размера. Это довольно быстро и беспроблемно работает и на уровне парадигм смотрится вменяемее того что zswap пытается изобразить. Zswap при серьезном душняке памяти видите ли систему уложит в ненавистные юзерам тупняки измеряемые минутами до того как стрельнет oom. А оно такое надо?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: