The OpenNET Project / Index page

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



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

Исходное сообщение
"Выпуск Debian 9.8"
Отправлено анонн, 17-Фев-19 22:50 
> Так вот, если вы не разобрались в проблеме - суть не в
> том что в fs побьются данные, которые только что писались -
> они не могут не побиться, и это совершенно нормально, а нормально
> спроектированная программа должна это пережить. Суть не в том что побьются
> метаданные, хотя journaled, cow, log-store fs изобретены сто лет назад и

Я-то может не разобрался, но вот проблема была как раз в системах с gmirror+журнал+unexpected poweroff.
Что и упоминалось в ответе:
> This is a problem that is endemic to all overwriting  filesystems that use journalling. Specifically, the journal only checks and corrects things that it knows need to be fixed.

Ну а чексуммы в журнал для метаданных в ext4 добавили конечно же исключительно от нечего делать или же неосиляния "правильной реализации", а не потому что принципиально невозможно сделать быструю журналируованную запись при отсутсвии возможности достоверного синка данных.

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

Ну да, ну да.
https://lwn.ext4 experience
> Posted Nov 30, 2011 4:52 UTC (Wed) by ringerc (subscriber, #3071)
> In reply to: ext4 experience by dskoll
> The usual culprit in those sorts of severe corruption or loss cases is aggressive write-back caching without battery backup. Some cheap RAID

https://opensource.com/article/18/4/ext4-filesystem


Journal checksumming

Ext3 did not checksum its journals, which presented problems for disk or controller devices with caches of their own, outside the kernel's direct control. If a controller or a disk with its own cache did writes out of order, it could break ext3's journaling transaction order, potentially corrupting files being written to during (or for some time preceding) a crash.

In theory, this problem is resolved by the use of write barriers—when
(...)
In practice, it's been discovered that storage devices and controllers frequently do not honor write barriers—improving performance (and benchmarks, where they're compared to their competitors) but opening up the possibility of data corruption that should have been prevented.

Я же говорю, что чексуммы просто из любви к искусству добавили.

> Суть в том, что в системе произойдет _silent_ corruption, который будет расти, пока не приведет к полному развалу fs.

Суть в том, что без чексум всех _данных_ - silent corruption может быть в любом случае.

 

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



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

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