The OpenNET Project / Index page

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



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

Оглавление

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

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


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

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

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




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

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