The OpenNET Project / Index page

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



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

Оглавление

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

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


31. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от Аноним (31), 04-Мрт-21, 23:40 
С какой радости?
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

45. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  –2 +/
Сообщение от AlexYeCu_not_logged (?), 05-Мрт-21, 00:03 
> С какой радости?

С такой, что отдельный раздел в первую очередь выделяли для лучшей производительности. Как только объёмы оперативной памяти позволили свести использование свапа к минимуму (а то и вовсе к нулю в ряде сценариев), то необходимость в лишней мороке и резервировании некоторого объёма дискового пространства отпала, ради копеечного выхлопа-то. Распространение ssd тоже поспособствовало — разница в скоростях между ssd и hdd куда больше таковой для раздел/файл.

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

51. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +2 +/
Сообщение от Аноним (31), 05-Мрт-21, 00:11 
Меньше необходимости в свопе как таковом != своп раздел "потерял актуальность", я бы сказал даже  вообще не имеет связи
Ответить | Правка | Наверх | Cообщить модератору

57. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от Аноним (48), 05-Мрт-21, 00:18 
Причём тут "объёмы оперативной памяти". Почитай, что ли, зачем вообще swap нужен (кроме OOM).
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

101. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 05-Мрт-21, 07:29 
>> С какой радости?
> С такой, что отдельный раздел в первую очередь выделяли для лучшей производительности.

Не знаю, за кого Вы тут говорите, но я создаю раздел подкачки и располагают его первым, что бы случайной ошибкой в команде dd не убить данные.

> Как только объёмы оперативной памяти позволили свести использование свапа

Да-да, объёмы памяти на SSD позволяют её немножко "выкинуть".

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

119. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (119), 05-Мрт-21, 09:46 
Отедльный раздел делали если правильно помню в конце диска, чтобы он попал на быстрее крутящийся край диска. Плюс линукс не умел свап в отдельных файлах. Потом научился, но файлы должны были быть нефрагментированы (не уверен здесь). Потом научился, но загружаться с таких разделов после гибернейта не умел.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

132. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от Oxyd76 (?), 05-Мрт-21, 10:25 
В начале. У диска дорожки начинаютя с краю.
Ответить | Правка | Наверх | Cообщить модератору

290. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 00:34 
> В начале. У диска дорожки начинаютя с краю.

Это более-менее похрену - у swap доступ довольно рандомный. Поэтому львиную долю времени HDD дергает головами чтобы вынуть очередной 4К кусочек. Время этого ничтожно по сравнению с seek и поиском нужного сектора.

Лучше всего не заниматься этой порнографией совсем, а ненужный трэш выгрузить в сжатый zram. Тогда даже в случае если это понадобится, латенси останется разумной, а в самом поганом OOM - ну, система потупит секунд 5-10 пока zram не закончится, после чего oom жестко пристрелит offender'а.

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

327. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 06-Мрт-21, 10:17 
HDD "дёргает" головку от файла с котиками (который расположен в начале) к области подкачки. Путь должен быть минимальным.
Ответить | Правка | Наверх | Cообщить модератору

336. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (336), 06-Мрт-21, 10:53 
> HDD "дёргает" головку от файла с котиками (который расположен в начале) к
> области подкачки. Путь должен быть минимальным.

Котиков никто постоянно не читает. А вот при активном своплении диск будет гонять головы по свопфайлу. Потому что когда памяти не хватает вообще всем по всем закоулкам, это что угодно кроме линейного доступа. При этом основное время уйдет на seek+поиск сектора а не чтение несчастных 4 кил, которые так то на нормальной скорости прилетают, но до этого пока там голова куда надо прилетит, успокоится, подвернется именно нужный сектор, ... это уже вообще совсем не как RAM получается.

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

347. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 06-Мрт-21, 11:21 
Интегральное счисление проходили?

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

364. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (364), 07-Мрт-21, 00:28 
> Интегральное счисление проходили?

Да, и именно поэтому можем прикинуть что суммарное улучшение от чуть более быстрого чтения сцаных 4 килобайтов при том что львиная доля времени убита на seek и поиск сектора (блин должен еще и повернуться правильно) - бесконечно малая величина. Ну, ок, не бесконечно.

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

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

376. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 07-Мрт-21, 08:24 
>> Интегральное счисление проходили?
> Да, и именно поэтому можем прикинуть что суммарное улучшение от чуть более

Так прикиньте. В математике нет определения для "чуть". Пока что Ваша гипотеза "более-менее похрену" остаётся необоснованной.

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

401. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от vlas (??), 12-Мрт-21, 16:40 
> в математике нет определения для "чуть"

пределы? асимптоты? фракталы? бесконечно малые величины? не, не слышал...

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

402. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 12-Мрт-21, 16:54 
>> в математике нет определения для "чуть"
> пределы? асимптоты? фракталы? бесконечно малые величины? не, не слышал...

Так то да, децл похоже на правду.

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

335. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Oxyd76 (?), 06-Мрт-21, 10:50 
Ну я всё-же предпочитаю приход великого и ужасного контроллировать. Как на серверах, где всё огорожено флажками контроллеров cgroup, так и на десктопе, где по наступлении критических параметров (превышение wa/la, втечении эвристическинайденного промежутка времени и определённых объёмов свопа и памяти) система выкидывает нотифи, после чего я, обычно, просто закрываю/открываю браузер. ;-)
Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

338. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (336), 06-Мрт-21, 10:56 
> Ну я всё-же предпочитаю приход великого и ужасного контроллировать. Как на серверах,
> где всё огорожено флажками контроллеров cgroup, так и на десктопе, где
> по наступлении критических параметров (превышение wa/la, втечении эвристическинайденного
> промежутка времени и определённых объёмов свопа и памяти) система выкидывает нотифи,
> после чего я, обычно, просто закрываю/открываю браузер. ;-)

А зачем мне самому дергаться, если оно либо более-менее нормально работает, либо oom выносит offender'а без моего участия? :)

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

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

391. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (390), 09-Мрт-21, 12:16 
Я видите ли инженер а не математик из того анекдота про огнетушитель и пожар. Поэтому предпочитаю радикальный подход к проблеме - вместо улучшения на пару процентов скорости thrashing сделать так чтобы thrashing вообще не было.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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