Theodore Ts'o выпустил (http://permalink.gmane.org/gmane.comp.file-systems.ext4/12179) патч к файловой системе ext4 с альтернативным решением проблемы (http://www.opennet.me/opennews/art.shtml?num=20715) с потерей данных в файлах, перезаписываемых незадолго до момента краха системы. В патче представлен новый режим журналирования "data=alloc_on_commit", похожий по своей сути на ext3 режим "data=ordered", при котором вначале изменяются данные, а потом изменения отражаются в журнале.
Включение "data=alloc_on_commit" приводит к введению двухфазовых коммитов, когда вначале в журнал помещается предварительная пометка, а после сброса блоков с отложенной записью (delayed allocation), в журнале окончательно фиксируется транзакция. Ожидается, что патч будет включен в состав Linux ядра 2.6.30.URL: http://permalink.gmane.org/gmane.comp.file-systems.ext4/12179
Новость: http://www.opennet.me/opennews/art.shtml?num=20835
плучается, что таким образом увеличивается время жизни транзакции в памяти. еще надо подумать, к ему это приведет.
к понижению скорости и повышению надежности при отключении питания.
а NILFS достаточно старая штука, одна из первых журнально-структурированных ФС. некий прообраз современных ZFS и btrfs. надо будет посмотреть код на досуге.
а с data=journal этот баг проявляется?
>а с data=journal этот баг проявляется?нет с самого начала, тестировал
Ню, теперь можно ставить на ноуты альфа-версии убунты и перемещать туда жизненно важные данные (перемещать, не копировать).
Теперь данные не потеряются и не придется делать удивленные глаза и вопрошать "а чего эта?")
> В патче представлен новый режим журналированияА он по дефолту какой оставит?Если тот при котором данные херятся - у юзеров они и дальше будут хериться, потому что дефолты - решают :)
>> В патче представлен новый режим журналирования
>
>А он по дефолту какой оставит?Если тот при котором данные херятся -
>у юзеров они и дальше будут хериться, потому что дефолты -
>решают :)Я думаю, по дефолту будет так, как поставят составители дистра)
Было бы хорошо если бы Теодор не раскладывал им грабли в дефолтах.Потому что кроме серьезных людей есть еще и доморощенные дистроклепатели а также красноглазики которых хлебом не корми, дай только пересобрать ядро, слепить систему с нуля из LFS и так далее.И когда (и если) благодаря таким начнется потеря данных у юзеров - будет слишком много ненужного воя.
> А он по дефолту какой оставит?"Неудобный" дефолт могут переопределить (fstab, tune2fs) дистрибутивостроители. Всё-таки ванильное ядро - не для домохозяек ;)
>"Неудобный" дефолт могут переопределитьНо куда лучше если дефолты будут безопасные, right?
в ubuntu по дефолту сейчас ничего не херится, специально тестил, а вот режим не знаю какой :(, скоре всего alloc_on_commit т.к. судя по тестам функционально очень похож.
Во-первых, в убунту 2.6.28 ядро. Патч включен в .30
Во-вторых, "херится" оно может только при крахе ибо данные могут оставаться незаписанными до 60 секунд.
именно это и тестировалось - ресет на активной работе с фс, и специально для ubuntu и fedora сделаны патчи... почитайте блог Теда, там всё написано
>Во-первых, в убунту 2.6.28 ядро. Патч включен в .30В Ubuntu не ванильное ядро, там вагон дополнительных патчей. Просто добавят еще один патч.
>Во-вторых, "херится" оно может только при крахе ибо данные могут оставаться незаписанными
>до 60 секунд.Способность противостоять случайным крахам/отключениям питания одна из ключевых характеристик ФС.
"В патче представлен новый режим журналирования "data=alloc_on_commit", похожий по своей сути на ext3 режим "data=ordered", при котором вначале изменяются данные, а потом изменения отражаются в журнале."До нормальных 15 лет назад дошло, а до самурая только щас да :)