The OpenNET Project / Index page

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



Индекс форумов
Составление сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



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

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