Исходное сообщение
"FreeBSD SoftUpdates vs журнал" Отправлено nuclight, 21-Мрт-09 22:37
По сути, если смотреть максимально обще, то фревый SostUpdates - это действительно такой специфический журнал, только существующий исключительно в памяти. И при сбое он теряется, то есть всегда выполняется rollback транзакций. >McKusick указал на два основных недостатка: >1) это сложность реализации (и соответсвенно отладки) >2) возможность утечки свободного дискового пространства при сбоях >Второй пункт рекомендует лечить фоновым fsck Да, именно сложность реализации и составляет основную проблему, а сама идея неплоха. Второй пункт появляется, поскольку на диске реального журнала нет, и если сбой случится в окно записи на диск, то будет ошибка. Однако SU построен таким образом, что класс таких ошибок очень ограничен (по большому счету пропажа места, ага), потому с введением бэкграундного fsck систему можно запускать сразу же на непроверенной fs, очень удобно, в отличие от форсированных проверок "180 дней на ext3 без fsck". Журнал не панацея, хехе. В общем, идея, повторюсь, неплоха, и вполне конкурентоспособна с журналом. Вот только из-за сложности реализации имеются проблемы - например в NetBSD с кодом задолбались и будут SU выкидывать. Печальный пример, как плохая реализация может убить хорошую идею.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> По сути, если смотреть максимально обще, то фревый SostUpdates - это действительно > такой специфический журнал, только существующий исключительно в памяти. И при сбое > он теряется, то есть всегда выполняется rollback транзакций. >>McKusick указал на два основных недостатка: >>1) это сложность реализации (и соответсвенно отладки) >>2) возможность утечки свободного дискового пространства при сбоях >>Второй пункт рекомендует лечить фоновым fsck > Да, именно сложность реализации и составляет основную проблему, а сама идея неплоха. > Второй пункт появляется, поскольку на диске реального журнала нет, и если > сбой случится в окно записи на диск, то будет ошибка. Однако > SU построен таким образом, что класс таких ошибок очень ограничен (по > большому счету пропажа места, ага), потому с введением бэкграундного fsck систему > можно запускать сразу же на непроверенной fs, очень удобно, в отличие > от форсированных проверок "180 дней на ext3 без fsck". Журнал не > панацея, хехе. > В общем, идея, повторюсь, неплоха, и вполне конкурентоспособна с журналом. Вот только > из-за сложности реализации имеются проблемы - например в NetBSD с кодом > задолбались и будут SU выкидывать. Печальный пример, как плохая реализация может > убить хорошую идею.
	Введите код, изображенный на картинке: