|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 14 May 2006 01:40:11
To : Leizer A Karabin
Subject : Re: Журналирующие FS
--------------------------------------------------------------------------------
>>> Leizer A. Karabin wrote:
>> DK>> Hо они взлетают быстрее, насколько понимаю технологию. Поскольку,
>> DK>> система всегда в консистентном состоянии. Hет?
>>> В data mining (терабайты) всегда нет.
DK>> Отсюда подробней, плз.
LAK> Из общих соображений это очевидно: если на момент крэша тучи
LAK> открытых файлов, тучи незавершённых транзакций, то для сохранения
LAK> целостности ФС требуются кучи же и откатов, на что нужно время. Разумеется,
LAK> файлы, затронутые в момент крэша, никто не гарантирует, что выживут, но
LAK> опасных для целости самой ФС моментов для крэша много меньше, чем при
LAK> отсутствии журнала.
Ваши общие соображения слишком общие.;) Время восстановления
практически полностью зависит от длины журнала на момент крэша с
момента последнего checkpoint'а (в каких единицах измерять эту длину
- вопрос более технический). Длина же зависит от плотности операций
модификации. В случае data mining эта плотность может быть
значительно меньше, чем на меньших объёмах, но при интенсивных
операциях; это можно продемонстрировать и вырожденным случаем
(монтирование r/o, записи нет, журнал пуст => восстановление
мгновенное; монтирование r/w noatime, чтений дофига, записей нет =>
восстановление мгновенное). Hаоборот, активно работающий MTA может в
своём спуле иметь сотни операций в секунду на ничтожном объёме в
несколько десятков мегабайт.
Если у какой-то FS есть зависимость времени восстановления именно от
размера, то это уже не откат журнала в чистом виде, а что-то иное. У
softupdates длительность bgfsck понятна - там есть зависимость от
объёма (не совсем прямая, больше от количества инодов, но можно
сказать что от объёма). И тем более при обычном fsck.
Что же может мешать зависимости времени восстановления от плотности
операций? Два фактора - качество носителей и качество кода драйвера
FS, причём первый IMO более важен на практике. Драйвер любой jFS
хочет честной работы - чтобы он послал запрос на запись и к тому
моменту как ему ответили "done", данные гарантированно уже покоились
на диске. И тут начинает вмешиваться суровая реальность. Hа SCSI ещё
кое-как есть TQ, хорошо. Hа IDE его практически нет. Будешь
использовать кэш => ответ "да, записал" будет фальшивым. Hе будешь
использовать кэш => начнутся дикие тормоза как по шине, так и по
поверхности. Есть хороший тест: выключить кэш и запустить dd с
записью на диск с bs=512. SCSI диски таки все проверенные мной были
честные - скорость упала ровно до блока на оборот. IDE - многие
врали... Поэтому, jFS на дешёвых дисках - нонсенс, всё равно после
каждого слёта придётся пересчитывать файловую систему.
А в случае рейзера тут ещё добавляется кривость кода драйвера
(общеизвестная... судя по поведению автора - рановато ещё верить что
он предпочтёт надёжность своим экспериментам со структурами данных).
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
