LINUX.ORG.RU

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

Исправление firkax, (текущая версия) :

Всё так, но

  1. Я как раз писал что отключений питания надо избегать, а то некоторые (как выше один уже отписался) думают что журнал это панацея
  2. Вопрос «стоит ли оно того» никуда не девается
  3. Непротиворечивость данных пользователя ФС может гарантировать только в рамках своей сферы деятельности, глобально же - нет; кроме ФС данные могут быть ещё в памяти или вообще на других машинах по сети, приложение может организовывать кеши на диске, которые разумеется станут противоречивыми с внешним миром после отката ФС, и writeback’и (в памяти, которая при сбое исченет), которые сведут на нет усилия ФС по локальной консистентности; я ни в коем случае не говорю, что эти «усилия ФС» из-за этого бесполезны, но надо понимать что транзакционная ФС не даёт полной гарантии (а вот исправный ИБП - почти даёт, если не будет kernel panic’ов). Если же говорить о доработке приложения для учёта всех факторов, то его можно и в рамках просто журналируемой ФС организовать весьма безопасно, если заранее всё продумать.

Исходная версия firkax, :

Всё так, но

  1. я как раз писал что отключений питания надо избегать, а то некоторые (как выше один уже отписался) думают что журнал это панацея
  2. вопрос «стоит ли оно того» никуда не девается
  3. непротиворечивость данных пользователя ФС может гарантировать только в рамках своей сферы деятельности, глобально же - нет; кроме ФС данные могут быть ещё в памяти или вообще на других машинах по сети, приложение может организовывать кеши на диске, которые разумеется станут противоречивыми с внешним миром после отката ФС, и writeback’и (в памяти, которая при сбое исченет), которые сведут на нет усилия ФС по локальной консистентности; я ни в коем случае не говорю, что эти «усилия ФС» из-за этого бесполезны, но надо понимать что транзакционная ФС не даёт полной гарантии (а вот исправный ИБП - почти даёт, если не будет kernel panic’ов)