The OpenNET Project / Index page

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



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

Оглавление

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

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


17. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  –3 +/
Сообщение от AlexYeCu_not_logged (?), 04-Мрт-21, 23:12 
>Кто-то ещё реально юзает своп-файлы вместо своп-разделов?

Ещё? Собственно, разделы-то как раз и потеряли актуальность лет так 10+ назад.

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

21. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +4 +/
Сообщение от YetAnotherOnanym (ok), 04-Мрт-21, 23:16 
Ага, вот как раз и доказательство подоспело.
Ответить | Правка | Наверх | Cообщить модератору

44. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  –2 +/
Сообщение от AlexYeCu_not_logged (?), 04-Мрт-21, 23:58 
> Ага, вот как раз и доказательство подоспело.

Ну терялись бы у тебя данные из-за записи за пределы _раздела_ закачки — сильно легче было бы?

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

48. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +2 +/
Сообщение от Аноним (48), 05-Мрт-21, 00:06 
Записать в другое блочное устройство - сильно сложнее, чем не по тому смещению в пределах одного блочного устройства.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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ообщить модератору

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

134. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Oxyd76 (?), 05-Мрт-21, 10:34 
Читайте сюда: https://habr.com/ru/post/540104/ и сюда: https://habr.com/ru/post/541214/
Ответить | Правка | Наверх | Cообщить модератору

146. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от ryoken (ok), 05-Мрт-21, 11:21 
> Читайте сюда: https://habr.com/ru/post/540104/ и сюда: https://habr.com/ru/post/541214/

Неполностью выразил идею, думал и так понятно будет. Чем лучше свап-файл вместо свап-раздела? (Статьи рассматривают именно файл). Хуже - вносится лишний уровень абстракций, подвержен фрагментации.

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

291. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 00:37 
> Неполностью выразил идею, думал и так понятно будет. Чем лучше свап-файл вместо
> свап-раздела? (Статьи рассматривают именно файл). Хуже - вносится лишний уровень абстракций,
> подвержен фрагментации.

1) Админить проще и гибче. Скажем если я решил отказаться от свопа, файл можно просто стереть. А раздел будет зазря место жрать, его так уже безопасно - сложно.
2) Лоскутное одеяло из разделов - на любителя.
3) Если у кого винда в дуалбуте можно реюзнуть 1 файл на двоих, зажав обоим размер свопа в фиксированные вот столько вот. Придется подкостылить т.к. форматы свопов разные но работать будет. И можно не хранить 2 раза одно и то же.

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

330. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 06-Мрт-21, 10:32 
> 3) Если у кого винда в дуалбуте можно реюзнуть 1 файл на
> двоих, зажав обоим размер свопа в фиксированные вот столько вот. Придется
> подкостылить т.к. форматы свопов разные но работать будет. И можно не
> хранить 2 раза одно и то же.

Это не шутка? У Вас Linux работает на NTFS?

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

339. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (336), 06-Мрт-21, 10:59 
> Это не шутка? У Вас Linux работает на NTFS?

Работал во времена ~убунты 5 или 6. А для винды, внезапно еще бывает ext2fsd например. И даже драйвер btrfs вроде какой-то.

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

345. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 06-Мрт-21, 11:16 
Какую задачу Вы решали таким способом?
Ответить | Правка | Наверх | Cообщить модератору

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

Трансфер себя любимого из винды в линукс. С миграцией всех данных. Плавно и без фаллаутов.

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

328. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 06-Мрт-21, 10:19 
Абстракции, это из живописи же! А тута одни технари. ;-)
Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

340. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (336), 06-Мрт-21, 11:00 
> Абстракции, это из живописи же! А тута одни технари. ;-)

Програмер без абстрактного мышления - инвалид умственного труда разве что.

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

344. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 06-Мрт-21, 11:16 
Беда этих тружеников мозгом в том, что в исходном контексте "лишний уровень абстракций" означает вполне материальные косвенные вызовы, как минимум.
Ответить | Правка | Наверх | Cообщить модератору

366. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 07-Мрт-21, 00:32 
> Беда этих тружеников мозгом в том, что в исходном контексте "лишний уровень
> абстракций" означает вполне материальные косвенные вызовы, как минимум.

Тем не менее, я считаю что про лишний уровень абстракций он в общем то более-менее нормально сказал. Если вы полагаете что можете оформить отсутствие лишнего layer of indirection лучше и без потери понятности - ну попробуйте.

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

378. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 07-Мрт-21, 08:46 
> оформить отсутствие

Вейп курите?

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

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

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




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

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