The OpenNET Project / Index page

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



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

Оглавление

В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews (??), 26-Май-23, (0) [смотреть все]

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


334. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +1 +/
Сообщение от maximnik0 (?), 31-Май-23, 10:50 
> Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка
> и папка это одна директория, открывающие случайные данные? Это та фс,
> где нет нормальных симлинков? Которая поддерживается примерно нигде

Сейчас с 64 мгб кэша на жестких любая фс при резком выключение может сказать -да ну его на "буй". Но обычно это не происходит,единственно что пишущие файлы вылетят в битые файлы.И симлинки и хардлинки данная фс поддерживает,софт не поддерживал,вот в этом беда.Даже больше скажу-ее можно было (хр,виста) под виндой монтировать если вы не знали.Да да,монтировать,а не буквой обозначать (кроме диска с). И не особо она медлительная-замечательно тюненгуеться,если стальные яйца можно даже журнал отключить.А с коммерческими драйверами спокойно под линь и 60 мгб выжимали.

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

403. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 03-Июн-23, 20:30 
> Сейчас с 64 мгб кэша на жестких любая фс при резком выключение
> может сказать -да ну его на "буй".

Вообще-то нет. Там есть команды для предсказуемой работы с кешированием и информирование хоста о фактическом завершении записи. И только после этого файлуха маркирует вон то как записаное а до этого оно считается "in flight" и на это нельзя уповать для критичных нужд.

Более того - в RAM хоста еще и не такой буфер и при слете питания или внезапном ребуте ТАМ пролюбится еще и не столько. Если fsync не делать, например. Самое интересное что даже чисто апликушный софт не может игнорить этот аспект под страхом мощной потери данных. Поэтому есть характерная семантика, а девайсы должны следовать определенным требованиям в реализации кеширования. Иначе файлухи имеют полное право неконтролируемо развалиться. На слет произвольных 64 мегов в любом месте никто корректно не реагирует. Если вы потеряете большой кус допустим метаданных - это достаточно критично.

> Но обычно это не происходит,единственно что пишущие файлы вылетят в битые файлы.

Это происходит потому что файлуха не журналила данные файла, инфо для undo/redo хватало только на метаданные и консистентность вида ФС в лучшем случае, а что там стало с файлом внутри - это очень отдельный вопрос. Потому и битый. Не будет произвольно взятая программа жрать наполовину старый, наполовину новый файл. А у виндовых ФС как я понимаю и оглавление диры иногда может пострадать, так что часть файлов оказывается как бы на месте, но как бы безымянными - потому что их дира разнесена вдрызг тем разлетом. Так что фс знает что аллокации есть но не знает как это называлось и где лежало, например.

> И симлинки и хардлинки данная фс поддерживает, софт не поддерживал, вот в этом беда.

От софта по логике вещей никакой особой поддержки и не надо в простых случаях.

> буквой обозначать (кроме диска с).

А у ядра NT унутрях вообще сильно другие пути так-то. Но вот совместимость...

> И не особо она медлительная-замечательно тюненгуеться,

Не выдерживает никакого сравнения с современными файлухами. Скиньте 50K-100К файлов в диру, ребутанитесь чтобы кеш очистить. А теперь попробуйте в эту диру на холодненькую зайти. И как вам времена чтения оглавления такой диры, хоть в какой проге?! Не нравится эксплорер, можно фар, или что там еще - на результат не влияет.

А теперь то же самое в линухе с какойнить иной фс. Ну там btrfs, ext4, etc. Почему там времена сильно более культурные? И тот же миднайт за весьма обозримое время это отрисовывает вот.

> если стальные яйца можно даже журнал отключить.

Никак не поможет при чтении списка 50К файлов на холодную. Вот и потюниговали :)

> А с коммерческими драйверами спокойно под линь и 60 мгб выжимали.

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

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

423. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от maximnik0 (?), 05-Июн-23, 22:02 
>Вообще-то нет. Там есть команды для предсказуемой работы с кешированием и информирование хоста о фактическом завершении записи.

То то в новых ядрах 1,5 сек задержку перед выключением пришлось возвращать (1,5 года назад). Есть команды но нет гарантии  что эти команды выполнены- очень разработчики ext4 с этим мучились, особенно на ноутбучных винтах был этот гемморой. Сейчас просто производителей жестких -на пальцах можно посчитать, но все равно глюки случаются,особенно с флэш дисками , а про аппаратное стирание на флэшках и говорить нечего.

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

426. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 06-Июн-23, 00:42 
> То то в новых ядрах 1,5 сек задержку перед выключением пришлось возвращать
> (1,5 года назад). Есть команды но нет гарантии

Да, вы знаете, фирмвары у девайсов бывают забагованые и кривые. Но это баг и нарушение спеков стандарта - и в этом случае предъявлять что либо ядру, фс и проч не айс. Если кто купил глюкало, пусть его MFRу и пеняет.

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

Но тут стоит понимать что воркэраунд в ядре - не решает проблему нарушения девайсом семантики на которую файлухи закладывались. Практически все ФС при журналинге и проч уповают на то что вон те операции с сбросом кеша - работают. Если это не так, крахи и слет питания ведут к UNDEFINE с практически любой ФС. Что там дальше будет - да что угодно в принципе. Это факап за пределами допущений ФС. Против лома нет приема.

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

Более того - такие приколы и у SD-card были. Нокия в свое время агресивно снимала питание с карт после команды шатдауна, как по спекам писано. И тут оказалось что как минимум Transcend спекам не соответствует и - отлично разлетается если так делать. И пришлось им ажно слать патчи в mmc подсистему ядра.

> а про аппаратное стирание на флэшках и говорить нечего.

Там максимальное время операций трекается машиной состояний и больше чем в спеках не будет, как максимум erase/program error в статусе чипа будет. Но пока до этого всего дойдет, там еще чертова куча кода фирмвары писаной хзкем. И у нее могли быть какие-то сильно свои идеи. Как показал пример допустим самса с EVO, иногда эти идеи бывают странные и они вот например TRIM нормално не смогли в некоторых девайсах, да так что девайс чуть не харакири себе делает с определенными сочетаниями запросов. Пришлось и это воркэраундить, заведя список гамняшек, с точностью до девайса и версии FW, их quirks, и явно избегать проблемные операции для таких.

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

И все же, по спекам так быть не должно. И ФС пишутся все же с опорой на эти спеки. Потому что ВСЕ мыслимые глюки ВСЕХ девайсов учесть на фазе дизайна не получится. А дальше уж пытаться воркэраундить в меру талантов. И вот тут оно может прокатить а может и нет. Разумеется новый дизайн на этапе проектирования может пытаться учесть траблы предшественников, но на 100% это нереально.

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

428. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от maximnik0 (?), 06-Июн-23, 13:45 
>Против лома нет приема.

Не знаю как в 10,не пробывал,а в старых версиях офтопика в настройках управления накопителя была опция запрета использования дискового кэша для записи. Там еще можно было другие алгоритмы кэширования сменить.Правда на скорости под офтопик это сказывается ощутимо, может из-за этого ходят байки о слишком сильной тормознутостьи ntfs, потому что драйвера (иногда биос) ряд чипов обнаружив ошибки записи принудительно отключали кэш на запись,и в некоторых случаях DMA доступ.(я знаю что с мелкими файлами в одном каталоге ext поведет себя гораздо лучше,но все равно если кэш пуст и она тупить будет).В linux тоже у hdparm была опция для отключения кэша диска для записи, так что не все так фатально.

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

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

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




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

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