|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 24 Oct 2005 17:15:08
To : Andrew Filonov
Subject : Выключение
--------------------------------------------------------------------------------
24 Oct 05, Andrew Filonov writes to Slawa Olhovchenkov:
SO>> А теперь попробуй аргументировать, почему при async'е более
SO>> вероятно получить битую fs.
AF> за счет большего временного интервала, в течение которого данные
AF> не соответствуют метаданным. См Handbook
Это не будет превращаться автоматом в битую fs.
SO>> Вот рассмотрим например теоретический предельный случай: очень
SO>> агрессивное кэширование и у нас никакие изменеие в метаданных на
SO>> диск вообще не писались. Да, данные при этом фактически
SO>> пропадут, но структура-то асталась неизменной и следовательно
SO>> целой.
AF> Обычно случаи сильно более другие.
И что? Кто-то действительно проводил их анализ? Я всего лишь показал, что все не
так уж однозначно и тривиально.
SO>> Другой вариант, кэширование было менее агрессивное, но из-за
SO>> ускорения работы все записи были завершены к моменту Т, а сбой
SO>> был в момент Т+Х. А при sync работа завершилась бы только к
SO>> моменту T+X+Y.
AF> Синхронная система находится в грязном состоянии только в интервале
AF> между записью данных и записью соответствующих метаданных,
AF> т.е. некие дискретные интервалы в диапазоне 0..Tsync
AF> Асинхронная - практически непрерывно в диапазоне 0...Tasync
AF> Само соотношение Tsync/Tasync - совершенно несущественно.
AF> С учетом того, что операций с диском как правило ведется более одной,
AF> асинхронная система является грязной почти всегда. В отличие от
AF> синхронной.
Ты опять путашь состояние в котором fs будет "битой" и в котором данные будут
поерянны. Это разные случаи!
SO>> Hету сравнения при одинаковых условиях. Т.е. два одинаковых
SO>> компа, выполняющих одинаковые запросы, но один в sync, а другой
SO>> -- в async. И сравнеине последствий.
AF> Hе бывает тут одинаковых условий - только статистика.
AF> Вот не помню я случаев, чтобы fs смонтированная sync потребовала бы
AF> ручного fsck (хотя у меня в свое время стояла железка, которая
AF> самопроизволно ребуталась раз в пару дней).
Hу и что? Это всего лишь особенности умолчаний в пограмме fsck_ufs, которые
легко меняются ключем -y.
... Автомат работает так: раз, два, три - и вас нет!
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
