История изменений

Нужно вести журнал, а это увеличивает число операций записи. Если при отключении питания ФС не может точно знать какие участки носителя при операции записи будут задеты, то это проблема.

А почему это она не знает?

Журналирование работает очень просто. Сначала мы пишем в журнал копию данных, которые будут записаны, вместе с адресом записи и чексуммой. Потом отправляем на диск команду «принудительно сбросить буферы и дождаться окончания всех операций записи» (назовём её командой X). После того, как буферы сброшены, мы записываем те же самые данные уже по месту. При сбое и перезагрузке мы сначала проверяем журнал — если в журнале каша и чексуммы не сходятся, значит, питание пропало в какой-то момент до команды X и содержимое журнала можно отбросить (а пользователю сказать, что записать не успели). Если же в журнале не каша, то питание пропало после команды X — значит, мы повторяем все операции по журналу в порядке их следования, и нам уже не важно, каша ли на диске или нет (потому что все эти данные мы запишем по новой).

Журналирование ломается только в одном случае — если команда X «врёт» и говорит, что всё готово, когда ещё не готово. А если диск при выполнении операции записи по тем или иным причинам способен повредить рядом лежащие сектора, то тут тебя уже ничего не спасёт, ни журналирование, ни без, такой диск можно только выкинуть на помойку.

Нужно вести журнал, а это увеличивает число операций записи. Если при отключении питания ФС не может точно знать какие участки носителя при операции записи будут задеты, то это проблема.

А почему это она не знает?

Журналирование работает очень просто. Сначала мы пишем в журнал копию данных, которые будут записаны, вместе с адресом записи и чексуммой. Потом отправляем на диск команду «принудительно сбросить буферы» (назовём её командой X). После того, как буферы сброшены, мы записываем те же самые данные уже по месту. При сбое и перезагрузке мы сначала проверяем журнал — если в журнале каша и чексуммы не сходятся, значит, питание пропало в какой-то момент до команды X и содержимое журнала можно отбросить (а пользователю сказать, что записать не успели). Если же в журнале не каша, то питание пропало после команды X — значит, мы повторяем все операции по журналу в порядке их следования, и нам уже не важно, каша ли на диске или нет (потому что все эти данные мы запишем по новой).

Журналирование ломается только в одном случае — если команда X «врёт» и говорит, что всё готово, когда ещё не готово. А если диск при выполнении операции записи по тем или иным причинам способен повредить рядом лежащие сектора, то тут тебя уже ничего не спасёт, ни журналирование, ни без, такой диск можно только выкинуть на помойку.

Нужно вести журнал, а это увеличивает число операций записи. Если при отключении питания ФС не может точно знать какие участки носителя при операции записи будут задеты, то это проблема.

А почему это она не знает?

Журналирование работает очень просто. Сначала мы пишем в журнал копию данных, которые будут записаны, вместе с адресом записи и чексуммой. Потом отправляем на диск команду «принудительно сбросить буферы» (назовём её командой X). После того, как буферы сброшены, мы записываем те же самые данные уже по месту. При сбое и перезагрузке мы сначала проверяем журнал — если в журнале каша и чексуммы не сходятся, значит, питание пропало в какой-то момент до команды X и содержимое журнала можно отбросить (а пользователю сказать, что записать не успели). Если же в журнале не каша, то питание пропало после команды X — значит, мы повторяем все операции по журналу в порядке их следования, и нам уже не важно, каша ли на диске или нет (потому что все эти данные мы запишем по новой).

Журналирование ломается только в одном случае — если команда X «врёт». А если диск при выполнении операции записи по тем или иным причинам способен повредить рядом лежащие сектора, то тут тебя уже ничего не спасёт, ни журналирование, ни без, такой диск можно только выкинуть на помойку.