The OpenNET Project / Index page

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



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

Оглавление

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

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


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

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

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

68. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от б.б. (?), 05-Мрт-21, 00:54 
Я юзаю. Потому что так мне своп не нужен, но фирефокс может намертво завесить всю систему, поэтому надо своп подрубать :)
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

292. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 00:39 
> Я юзаю. Потому что так мне своп не нужен, но фирефокс может
> намертво завесить всю систему, поэтому надо своп подрубать :)

Открой для себя zram, для древнего барахла и душняка рамы просто клад. Если у хлама слабый проц, lz4 как алгоритм бери. А если сильный, LZO+RLE из новых кернелов. Или даже zlib если тормозов не боишься. Но по сравнению с LZ4 zlib распаковывается медленней раз так в 10-20.

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

75. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Ordu (ok), 05-Мрт-21, 04:16 
Я юзаю. И не "ещё", а уже. Лет десять уже как. Раздел он только под ногами путается, и когда вдруг приходит мысль всё куда-нибудь подвигать, то необходимость переразбивать диск только потому, что мне захотелось swap перекинуть на другой диск -- это сакс. Таблица разделов вообще такая штука, которую лучше не трогать почём зря. Целее будет.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

109. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 05-Мрт-21, 08:51 
Ну я под разделами в т.ч. тома LVM понимаю, поэтому никаких особых указанных проблем у меня с разделами не существует :D Типовая конфигурация для не-загрузочных дисков - LVM сразу поверх физики, никаких разделов.
Ответить | Правка | Наверх | Cообщить модератору

110. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 05-Мрт-21, 08:51 
// никаких MBR/GPT разделов //
Ответить | Правка | Наверх | Cообщить модератору

236. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (207), 05-Мрт-21, 18:30 
> // никаких MBR/GPT разделов //

А выравнивать кто будет?

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

256. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 05-Мрт-21, 20:40 
Выравнивать щито?
LVM на физику "с 0", размер блока LVM больше блока диска. Т.е. всё априори выровнено.
Ответить | Правка | Наверх | Cообщить модератору

260. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (207), 05-Мрт-21, 20:55 
Нет. Но современный lvm2 умеет выравнивать автоматически (data_alignment_detection/data_alignment_offset_detection) и dataalignmentoffset не нужно указывать как я понял.
Ответить | Правка | Наверх | Cообщить модератору

262. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 05-Мрт-21, 21:05 
Ну блин. Если у тебя pv начинается с начала диска и размер блока распределения мегабайт 16-128 - что у тебя там может быть не выровнено?

Более того, physical_block_size / logical_block_size LVM учитывает автоматически.

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

264. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (207), 05-Мрт-21, 21:33 
Так смещение данных там всё равно не будет корректным по секторам наверно (оно может отличаться). Оно может попытаться задетектить само (раньше такое размещение было не рекомендовано емнип).
Ответить | Правка | Наверх | Cообщить модератору

274. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 05-Мрт-21, 22:39 
Если размер блока FS на описанном выше LVM-томе > размера блока диска, всё также будет выровнено.
Обыкновенная математика, чего гадаете-то?
Ответить | Правка | Наверх | Cообщить модератору

275. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 05-Мрт-21, 22:40 
Размер блока диска является целочисленным делителем для любой позиции блока данных, выраженной в количестве байт от старта диска, в описанном случае.
Ответить | Правка | Наверх | Cообщить модератору

307. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 01:52 
> Размер блока диска является целочисленным делителем для любой позиции блока данных, выраженной
> в количестве байт от старта диска, в описанном случае.

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

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

324. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 06-Мрт-21, 10:00 
Он может врать сколько угодно, если размер блока FS допустим 4К (а меньше нет смысла ныне использовать), то все уже выровнено. В случае "флеша" с контроллером, буфером и левелингом вообще можно ничего особо не выравнивать, драйв всё равно в фоне пишет так, как ему заблагорассудится.
Ответить | Правка | Наверх | Cообщить модератору

341. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (341), 06-Мрт-21, 11:03 
> Он может врать сколько угодно, если размер блока FS допустим 4К (а
> меньше нет смысла ныне использовать), то все уже выровнено.

Там еще свои приколы бывают с нумерацией секторов, в ранних 4К моделях которые с икспой, чтоли, совместимость сохраняли, или типа того.

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

Вообще, лучше попасть по границам erase block/group и pages. Иначе write amplification может на ровном месте образоваться. А так винч тоже читает-пишет как ему там удобнее. Ему дают только логический номер сектора и данные, а куда и что он с этим - сильно отдельный вопрос. Какой-нибудь черепичный может довольно много странных вещей делать вроде.

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

346. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 06-Мрт-21, 11:20 
> Вообще, лучше попасть по границам erase block/group и pages. Иначе write amplification
> может на ровном месте образоваться.

Эти данные современные SSD операционке не выдают. Более того, в самой NAND вполне может быть зонирование с разным размером блоков, динамическое зонирование по количеству бит на ячейку в блоках (самое известное - динамический буфер SLC), и т.д., и т.п.

С "черепичными" HDD уже давно то же самое - чёрт ногу сломит в зонировании, поэтому общий подход - выровнял по границе блока и забыл, всё остальное - извращение и игра в угадайку.

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

367. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 07-Мрт-21, 00:38 
> Эти данные современные SSD операционке не выдают.

Они бывают кратны размеру erase block * N где N - число параллельно зацепленных к контроллеру флешаков. Erase block указан в даташитах. В среднем по больнице можно на примерно 64..128 мегов выравнивать. Это и на границы pages не попадет, и по eraseblock-ам скорее всего нормально разложится.

> Более того, в самой NAND вполне может быть зонирование с разным размером блоков,
> динамическое зонирование по количеству бит на ячейку в блоках (самое известное
> - динамический буфер SLC), и т.д., и т.п.

Может быть много чего. Все не угадать, разумеется. Хотя есть тулсы пытающиеся эмпирически прикинуть параметры, с переменным успехом.

> С "черепичными" HDD уже давно то же самое - чёрт ногу сломит
> в зонировании, поэтому общий подход - выровнял по границе блока и
> забыл, всё остальное - извращение и игра в угадайку.

Игра в угадайку повышает вероятность выигрыша, если делать ее осмысленно.

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

348. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 06-Мрт-21, 11:22 
С write amplification кстати флеши борятся года с 2002 так нормально, обычно это двухуровневый левелинг, где отдельные "логические секторы" могут оказаться размазанными по нескольким блокам. На них будет не write, а read amplification, чтобы блок собрать, но чтение шустрее.
Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

349. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 06-Мрт-21, 11:28 
Двухуровневый левлинг - в смысле двухслойный wear leveling, где нижний уровень отвечает за wear leveling собственно блоков флеша, а второй вполне может запихать участки блока при неполной перезаписи в другой блок - и потом либо дропнуть, если будет полная перезапись блока записи, либо собрать, когда от нижнего уровня придёт запрос на освобождение блока (данные в флеше деградируют со временем, поэтому там есть цикл рефреша). Это ещё в 2002 году было, сейчас скорее всего стало ещё сложнее.
Ответить | Правка | К родителю #348 | Наверх | Cообщить модератору

368. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 07-Мрт-21, 00:43 
> С write amplification кстати флеши борятся года с 2002 так нормально, обычно
> это двухуровневый левелинг, где отдельные "логические секторы" могут оказаться размазанными
> по нескольким блокам. На них будет не write, а read amplification,

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

> чтобы блок собрать, но чтение шустрее.

С чего это сборка фрагментов + лишняя трансляция "шустрее"?

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

293. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 00:41 
> Нет. Но современный lvm2 умеет выравнивать автоматически

А зачем свопу начинающемуся с начала диска выравнивание? Алсо, даже fdisk и ко научились малость этому самому. Как и человекочитаемым размерам.

Ну и механическому винчу важно только с точностью до сектора, а ssd вообще помрет влет от активного свопа, нафиг надо.

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

152. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  –1 +/
Сообщение от Аноним (152), 05-Мрт-21, 11:51 
LVM как-то отменяет необходимость ресайзить ФС после передвижения разделов?
Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

195. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Онаним (?), 05-Мрт-21, 14:18 
> LVM как-то отменяет необходимость ресайзить ФС после передвижения разделов?

LVM отменяет необходимость ребута для изменения таблицы разделов без отмонтирования.

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

294. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 00:46 
> LVM отменяет необходимость ребута для изменения таблицы разделов без отмонтирования.

Вот тебе раз?! А как я тогда ресайзнул вот сейчас раздел - изменив таблицу разделов? Под смонтированной фс (это рутфс, кроме нее и нет нихрена).

А дальше - только подумайте, fdisk (и большинство остальных) допирает отвесить кернелу характерный сискол (или это был ioctl?) - форсирующий чтение таблицы разделов заново. Есть еще какой-то файлик в sys или proc для форсирования этого еще 1 методом, IIRC.

А потом просто btrfs fi resize +max / и оно жрет появившееся новое место (идея в том что образ компактный, но если стораж крупнее, делается grow rootfs до хвоста стоража).

А, да, и никаких LVM. Может у покусаных редгадом некромантов крыша то - совсем ку-ку? Ты не альт поха случаем? Больно уж синхронно затупляете.

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

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

При том единственный "раздел" реально имеющий смысл - zram :P. Эмулировать оперативку винчом или SSD - надо быть мазохистом. В первом случе терпеливым, во втором - богатым.

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

96. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от ИмяХ (?), 05-Мрт-21, 06:27 
В винде он уже давно есть по умолчанию. Причём он динамически расширяется.
Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

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

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

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

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

Потому что zram предназначен для эмуляции блочных устройств, что бы файлы располагать в памяти и быстро с ними работать. А для сжатия подкачки разработан zswap. Но родившиеся после выпуска i80386 эксперты двигают zram на место zswap, в результате чего последний недостаточно оттестирован.

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

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

Как сжатый своп он тоже очень прилично работает. Своп, внезапно, тоже блочное устройство.

> место zswap, в результате чего последний недостаточно оттестирован.

Унылая фигня. Потому что сжатие у него сделано мутно - и не отменяет траффика к диску. Это протирает SSD, дико тупит механикой, и в общем то не решает кардинально ни 1 проблемы по сравнению с обычным свопом. В то время как система с свопом только zram даже OOM отстреливает за секунды - и это вообще в целом low latency решение, что для десктопа актуально. Как угодно но время декомпрессии страницы RAM -> RAM не имеет ничего общего с IO к механическому диску и не протирает NVM-диск с ограниченым ресурсом, RAM не обижается даже на очень интенсивный своп.

Но у опоздавщих включить мозг из обоснований своей правоты видимо только понты.

> в результате чего последний недостаточно оттестирован.

И хрен бы с ним. Пусть его тестируют те кому нравится хруст диском или протирание SSD. А с системой где своп только в zram этого всего - нет. Есть прозрачная компрессия кусочка оперативки, не более заданного размера. Это довольно быстро и беспроблемно работает и на уровне парадигм смотрится вменяемее того что zswap пытается изобразить. Zswap при серьезном душняке памяти видите ли систему уложит в ненавистные юзерам тупняки измеряемые минутами до того как стрельнет oom. А оно такое надо?

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

321. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 06-Мрт-21, 09:04 
> Своп, внезапно, тоже блочное
> устройство.

Увы, друг Горацио, подкачка - это механизм отображения виртуальной памяти на физическую. Или наоборот? ;)

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

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

Это лишь одна из ипостасей paging. Не факт что главная.

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

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

Раз Вы не смогли ответить на предыдущий вопрос, возникает другой. С датой выпуска i80386 я угадал?

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

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

394. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от n00by (ok), 09-Мрт-21, 15:02 
Вижу. Точно такую же туфту я гнал на экзамене по философии. Там она была в тему.
Ответить | Правка | Наверх | Cообщить модератору

122. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от z (??), 05-Мрт-21, 09:50 
> Послушай, если zram такой хороший, тогда почему его не сделают по умолчанию в дистрибутивах?

В Fedora сделали.

В Ubuntu предлагают своп-файл - это позорище.

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

217. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Michael Shigorinemail (ok), 05-Мрт-21, 16:47 
>> Послушай, если zram такой хороший, тогда почему его не сделают
>> по умолчанию в дистрибутивах?
> В Fedora сделали.

В альте как минимум в крабочей станции сделали.

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

121. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от z (??), 05-Мрт-21, 09:49 
> Кто-то ещё реально юзает своп-файлы вместо своп-разделов?

Кто-то ещё реально юзает своп-разделы вместо свопа на устройстве zram?

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

137. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от Онаним (?), 05-Мрт-21, 10:43 
Да, а что?
Под zram на малых VPS не всегда есть достаточно свободной памяти, наличие zram может ситуацию ухудшить, а не улучшить.
Ответить | Правка | Наверх | Cообщить модератору

297. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 01:04 
> Под zram на малых VPS не всегда есть достаточно свободной памяти, наличие
> zram может ситуацию ухудшить, а не улучшить.

При разумном использовании он даже на роутере с 32 мегами оперативы ситуацию как раз таки здорово улучшает. Предоставляя место для выгрузки холодных страниц но без диких тупняков даже если они потом все же понадобятся.

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

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

147. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +1 +/
Сообщение от ryoken (ok), 05-Мрт-21, 11:23 
>  Кто-то ещё реально юзает своп-разделы вместо свопа на устройстве zram?

Ну я. Проясните для неразбирающегося - а из чего делается zram? Если он из оперативы, то это вдвойне бессмысленное занятие.

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

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

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

298. "Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..."  +/
Сообщение от Аноним (-), 06-Мрт-21, 01:08 
> Ну я. Проясните для неразбирающегося - а из чего делается zram? Если
> он из оперативы, то это вдвойне бессмысленное занятие.

Есть один нюанс - там сжатие есть. Поэтому да, это своп из RAM в RAM. Но фокус в том что отсвапленое СЖАТО. И занимает меньше места. А когда потребуется снова - кернел распакует эту страницу и вернет ее.

Есть еще zswap, но те кто его дизайнил был на дизайнерских веществах. Иначе не понятно как можно столько наинженерить, не решив по большому счету ни одной из ключевых проблем свопа. Главное - цать минут тупняков до OOM'а, конечно, которые всех бесят, и которые упираются в IO с медленным винчом. Или как вариант SSD протрет до дыр влет. В zram таких проблем нет как класса. Это сжатая оперативы, там другие скорости и латенси при вообще совсем любых раскладах :)

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

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

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




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

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