 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Aleksey Barabanov 2:5020/400 05 Feb 2006 23:04:23 To : Oleg Drokin Subject : Re: reizerfs-suxx?//в завершение темы -------------------------------------------------------------------------------- Oleg Drokin wrote: > Hет. Все дело в том, что журнал имеет конечный объем. Пусть 32 мегабайта. > И когда он переполняется, новые блоки продолжают писаться с начала, > то есть имеет место переход головки назад. Если изначально головка была > ближе к началу журнала, то запишет последние несколько блоков и commit А чего ей там делать? Как она туда попала? > record, потом побежит вперед и там запишет header и начальную порцию > блоков. Если питание пропадет после успешной записи header в таком > сценарии - то привет. > Схожая ситуация может возникнуть при апдейте last committed в суперблоке > и записью непосредственно самих данных. Опять же почему вдруг это произойдет в такой последоватльности, а не в порядке поступления операций в кеш. Теперь посчитаем сколько есть таких вероятных расстановок. И сколько из них приведут к проблеме. Учтите кстати объем кеша и то, что кроме метаданных туда попадут еще и реальные данные. Т.е. соотношение и тех и других. Все это к тому, что реальная вероятность неблагоприятных ситуаций несколько иная. > AB> Hе факт, что даже те устройства, которые декларируют запрет write > cache, не AB> обманывают на самом деле. > > Ясное дело, более того, есть некоторые винты которые именно так и > поступают. WD вроде какие-то, например. В кернеле есть blacklist на эту > тему, как я помню. И предположу, что со временем это скорее всего войдет в норму. Ибо иначе представьте, что произойдет если все начнут запрещать кеш записи. > Кто сказал что кеш fifo? Кеш там "что ближе, то и запишу". А кто сказал, что работу журнала не сопровождают командами flush cache? Кстати, тогда получается, что если дополнительная интелектуальность дисковых устойств не сопровождается дополнительной гарантией сброса буфера, то такие девайсы должны приводить к проблемам в работе. Из SAS устройств это должно относиться к промежуточных псевдохардверным контроллерам рейдов. Если используется стандартный драйвер посылающий время от времени команды очистки кеша в расчете на небольшой его размер, то контроллер рейда с дополнительным кешем должен будет их игнорировать иначе просто станет тормозить. И в результате неизбежно будут проблемы. ;) Всегда использую только софтовый рейд ;) -- Bye. Aleksey Barabanov <alekseybb at mail.ru> Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5.3 * Origin: home (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/78244cce5d70.html, оценка из 5, голосов 10
|
|
|