The OpenNET Project / Index page

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



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

Исходное сообщение
"В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."
Отправлено Аноним, 30-Май-20 09:20 
> CoW это метод оптимизации использования носителя, он не избавляет от необходимости делать
> новый файл с последующей подменой.

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

> Тем более для общего случая CoW вреден т.к. новый файл может измениться радикально для CoW.

Это неверное утверждение. CoW - "другой по свойствам". При "радикальном изменении" это не такая уж проблема: в лучшем случае файл быренько 1 куском выжмется в новый extent, желательно непрерывный. На него "переназначат указатели" со старого, грубо говоря, и дело в шляпе. Это само по себе и быстро, и не имеет причин плохо работать, и совсем не портит предыдущий вариант файла на случай если что-то все же пошло не так. Так что это полный журнал со скоростью записи как без журнала вообще. Всегда есть и прошлый вид на который можно отмотать и новый. А когда-нибудь потом GC, конечно, освободит неиспользуемые блоки старого вида файла, чтобы место не кончилось.

Реальные проблемы для CoW являет именно случай типа СУБД, с мелким inplace патчингом кусочков. В долговременном плане при активной записи это ведет к куче мелких фрагментиков делаемых "сбоку" по всему диску и огромному объему метаданных для описания этого. Поэтому оракл и хотел отключку CoW - для своих баз, они получат in-place представление, cow не будет фрагменты фигачить, а журнал оно себе само и делало по жизни.

> Это может быть в любом случае, нельзя изменить любой файл за один
> write(...) с логом в ФС.

В случае CoW все иначе. Старое состояние уже есть, его не надо делать и на него можно вернуться, просто игноря вон те изменения. Write() записывает блоки куда-то в сторону - и не портит старое состояние. Если все это получилось, метаданные апдейтятся чтобы указывать уже на новые блоки (это быстро). Конкретно btrfs делает этот номер еще и с самими метаданными, поэтому в нем то же самое касается и метаданных. В случае краха достаточно забить на свежезаписанные куски - и ВНЕЗАПНО получается предыдущее состояние и данных и метаданных. Логически корректное. А то что это журналинг с совсем другого бока - ух ты, а так можно было.

 

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



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

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