|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Drokin 2:5020/400 05 Feb 2006 23:55:45
To : Aleksey Barabanov
Subject : Re: reizerfs-suxx?//в завершение темы
--------------------------------------------------------------------------------
Hello!
Aleksey Barabanov <abb@wessen.ru> wrote:
>> Hет. Все дело в том, что журнал имеет конечный объем. Пусть 32 мегабайта.
>> И когда он переполняется, новые блоки продолжают писаться с начала,
>> то есть имеет место переход головки назад. Если изначально головка была
>> ближе к началу журнала, то запишет последние несколько блоков и commit
AB> А чего ей там делать? Как она туда попала?
Суперблок апдейтила, например (он в 18м блоке живет, потом journal sb,
а потом уже сам журнал). Он часто апдейтится.
>> record, потом побежит вперед и там запишет header и начальную порцию
>> блоков. Если питание пропадет после успешной записи header в таком
>> сценарии - то привет.
>> Схожая ситуация может возникнуть при апдейте last committed в суперблоке
>> и записью непосредственно самих данных.
AB> Опять же почему вдруг это произойдет в такой последоватльности, а не в
AB> порядке поступления операций в кеш.
Потому что смысл writeback cache в том чтобы побольше данных в себя принять
и записать их как можно быстрее (то есть с минимальным head movements)
AB> Теперь посчитаем сколько есть таких вероятных расстановок. И сколько из них
AB> приведут к проблеме.
Сколько бы их не было, периодически они происходят.
AB> Учтите кстати объем кеша и то, что кроме метаданных туда попадут еще и
AB> реальные данные. Т.е. соотношение и тех и других.
Просто данные висят в кеше (в случае journal mode = writeback) по 30
секунд и не жужжат ;)
AB> Все это к тому, что реальная вероятность неблагоприятных ситуаций несколько
AB> иная.
Hу так никто ж не утверждает что вероятность 100%.
Hо она выше чем у других неблагоприятных событий, сдается мне.
>> AB> Hе факт, что даже те устройства, которые декларируют запрет write
>> cache, не AB> обманывают на самом деле.
>> Ясное дело, более того, есть некоторые винты которые именно так и
>> поступают. WD вроде какие-то, например. В кернеле есть blacklist на эту
>> тему, как я помню.
AB> И предположу, что со временем это скорее всего войдет в норму. Ибо иначе
AB> представьте, что произойдет если все начнут запрещать кеш записи.
Так никто его не запрещает как правило!
А эти добрые дяди еще и cache flush реализовали как noop, помнится, в некоторых
моделях.
>> Кто сказал что кеш fifo? Кеш там "что ближе, то и запишу".
AB> А кто сказал, что работу журнала не сопровождают командами flush cache?
Только если диск это умеет, к тому же такое сопровождение появилось не так
давно в 2.6, а в 2.4 нету до сих пор, помоему.
И далеко не везде этот cache-flush даже просто включается.
$ dmesg | grep flush
hda: cache flushes not supported
hdb: cache flushes not supported
$ dmesg | grep flush
hda: cache flushes supported
$ pdsh -w akane,ranma 'dmesg | grep flush'
ranma: hda: cache flushes supported
akane: hda: cache flushes supported
akane: reiserfs: using flush barriers
akane: reiserfs: enabling write barrier flush mode
(обратите внимание как часто даже имеющийся механизм используется ;) ).
(О! Я тут в коде поковырялся, а оно по умолчанию запрещено! ;) А там где
сообщение печатается - как раз загружено SLES9 ядро, просто ).
Плюс всякие RAID/LVM/прочие друзья не умеют передавать flush флаг на реальный
девайс, как я припоминаю, поэтому там это тоже не работает.
AB> Кстати, тогда получается, что если дополнительная интелектуальность дисковых
AB> устойств не сопровождается дополнительной гарантией сброса буфера, то такие
AB> девайсы должны приводить к проблемам в работе. Из SAS устройств это должно
И приводят.
AB> относиться к промежуточных псевдохардверным контроллерам рейдов. Если
AB> используется стандартный драйвер посылающий время от времени команды
AB> очистки кеша в расчете на небольшой его размер, то контроллер рейда с
AB> дополнительным кешем должен будет их игнорировать иначе просто станет
AB> тормозить. И в результате неизбежно будут проблемы.
При использовании TCQ, например, блок можно пометить как "не записывай меня,
пока все остальные блоки сунутые в кеш передомной не запишешь" и все счастливы.
AB> Всегда использую только софтовый рейд ;)
Может и зря ? ;)
Bye,
Oleg
--- ifmail v.2.15dev5.3
* Origin: Green's home news server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
