The OpenNET Project / Index page

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



"FreeBSD-CURRENT переведён по умолчанию на Clang"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "FreeBSD-CURRENT переведён по умолчанию на Clang" –1 +/
Сообщение от iZEN (ok), 16-Ноя-12, 16:29 
>> Поэтому для Ext* нужно задействовать барьеры записи.
> И не только для ext* - не тешь себя надеждами.
>> А для UFS2, благодаря SoftUpdates, очередь транзакций находится в памяти, транзакции сбрасываются на диск с ощутимой задержкой, достаточной для того, чтобы контроллер начал
>> запись
> А ты дашь гарантию того, что "контроллер начнёт запись" вовремя? На каких,
> собственно, основаниях? Кто мешает контроллеру держать данные в буфере до накопления
> достаточного их объёма?

Примерно раз в 20-30 секунд делается автоматический снапшот UFS2 с фиксацией завешённых транзакций (.snap). 30 секунд — это то время, за которое контроллер либо успевает сбросить данные на диск в любой последовательности, либо не успевает (авария по питанию), и ФС делается "немного" больно — всё зависит от важности данных. Метаданные "между" снапшотами не деградируют. При перезагрузке метаданные откатываются на момент последней своей фиксации в снапшоте, а вот свободное место для данных уменьшается на тот объём, который успел записаться, но не отражён в метаданных, и его можно/нужно вернуть силами fsck, выполняемой в фоне, основываясь на данных из снапшота. Фактически происходит синхронизация метаданных и данных из снапшота с испорченной ФС в реальном времени. fsck на UFS2 работает со снапшотом и с полуживой ФС одновременно, восстанавливая из снапшота утраченную информацию о консистентности, так как снапшот — это единственная верная картина о состоянии ФС, зафиксированная во времени. Если во время аварии какие-то файлы изменялись и переписывались, то это отражается найденными "хвостами" в каталоге .lost+found — как в любой другой классической ФС. Это механика SU вкратце.

>> и не делал в обратном случае никаких переупорядочиваний. Потеря записи одной
>> транзакции
> Ты не понимаешь. Без барьера контроллер может записать твою транзакцию N+100, но
> не записать N+10 и N+50, ожидая, что ты его покормишь еще
> данными, чтобы записать сразу большой блок. Или - "о ужас" -
> записать куски от твоих транзакций - перемешав очередность данных и метаданных.

Без барьеров можно обойтись, просто сделав настолько большую паузу между пересылкой данных из памяти в буфер контроллера, и настолько больший пакет данных, чтобы с одной стороны: заставить контроллер хоть что-то писать по таймауту (30 секунд это мало?); с другой стороны: заставить его же писать по переполнению буфера без таймаута.

>>> Вот тут и появляется механизм барьеров, который как раз и позволяет _упорядочить_
>>> транзакции сквозняком, вплоть до записи на диск.
>> Вот я и говорю: для Linux Ext* обязательно включаем барьеры на запись.
> Для любой FS, если мы хотим целостности. Нет, на хомячковых ПК, где
> контроллер сразу пишет на диск - всё нормально (да и то
> не всегда - у современных дисков бывают кэши приличного объёма, и
> отключение питания - не редкость).

Чем больше кэш у контроллера, тем больше резервируется буфер в памяти для упорядочивания очереди транзакций, тем дольше данные не сбрасываются на диск, тем реже делаются автоснапшоты ФС UFS2 — я так понимаю логику работы SU.

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

Оглавление
FreeBSD-CURRENT переведён по умолчанию на Clang, opennews, 06-Ноя-12, 00:25  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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