>> Поэтому для 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.
