Haiku OS → BFS - перевод статьи Эндрю Хадсона (часть 3)
Третья и заключительная часть.
Журнал
Есть много причин приводящих к выводу из строя жестокого диска. Магнитный материал сектора диска может разложиться, может отказать механизм сервомотора, может отказать электроника или пользователь может перезагрузить машину в середине операции записи на диск. Если Вы достаточно долго используете свой диск, в конце концов, электроника или механика жесткого диска выйдет из строя. И, к сожалению, самое распространение явление разрушительно влияющая на файловую систему — это нетерпеливые пользователи, прерывающие работу компьютера во время операций записи файла.
Рассмотрим следующую ситуацию. Пользователь создал файл, и это — процесс сохранения его на диск. Возможно это разработчик работающий над просроченным проектом. Файловая система должна сделать несколько обновлений прежде, чем файл будет полностью сохранен. В первую очередь сохранить содержимое файла. Она должна сохранить метаданные файла, дату создания, владельца, размер файла и т.д. А также обновить суперблок. Рассмотрим что происходит при выключении питания, прежде чем операция будет завершена. В дополнении к потере Вашей работы, может быть повреждена структура данных указывающая на i-node и блоки, которых не существует. Также это может привести к невозможности загрузки файловой системы и потере других Ваших файлов.
Ведение журнала облегчает решение этих проблем. Хотя журнал и не гарантирует, что преждевременная перезагрузка не приведет к потере Вашего файла, но по крайней мере это не вызовет повреждение файловой системы.
Рассмотрим пример работы журнала. Предположим что пользователь создает новый файл и сохраняет его. Данные должны быть сохранены на диск, также должна быть сохранена новая директория с правильными метаданными. До выполнения этих дисковых операций, BFS запирает не записанные блоки в оперативную память и ведет записи в журнал файловой системы для каждого блока, который должен быть записан. После того как каждый блок успешно записывается на диск, журнал помечает запись как выполненную. Если система будет перезагружена прежде, чем блоки будут успешно сохранены, в журнале будут помечены не выполненные операции. При рестарте системы, она проверяет журнал на наличие невыполненных операций. Эти записи могут быть “переиграны” для успешного выполнения операции или может быть выполнен “откат” и операция прервется. Так или иначе, но файловая система остается в согласованном состоянии, где структура каталогов и метаданных точного соответствует данным файла.
В BFS журнал регистрирует любые изменения произведенные в каталоге, в блоке bitmap, i-node и расширенных атрибутах. Таким образом ведение журнала защищает файловую систему, но не обеспечивает возможности восстановления файлов как избыточный массив дисков или RAID.
Нет защиты от всех дисковых ошибок, BFS устойчива к преждевременным выключениям системы. Файловые системы не ведущие журнал, такие как ext2, уязвимы к несогласованности и полагаются на длительные процессы сканирования для восстановления. BFS не нуждается в сканировании дисков и Haiku может начать работу сразу после внезапного выключения.
Усовершенствования Haiku BFS в сравнении с BeOS
Версия Haiku BFS имеет ряд улучшений по сравнению с оригинальной реализацией BeOS BFS. B+tree более надежен. Haiku BFS использует кэш данных файла, в дополнении к кэшу блоков. Это привело к десятикратному увеличению скорости. POSIX atime file был убран из BeOS BFS для увеличения производительности. Haiku BFS включает оптимизированный запрос для гибридных регулярных выражений, которое позволяет смешивать статическую строку с регулярным выражением. Новые инструменты bfsinfo, bfswhich, chkindex, и recover были добавлены в Haiku BFS. Для улучшения индексации расширенных атрибутов добавлена команда reindex.
Короткое интервью с ведущим разработчиком BeOS, который работал над BFS.
(Он попросил не использовать его имени, чтобы выполнить пожелания своего нынешнего работодателя)
Как много уходит времени на написание и отладку кода от концепции до релиза?
Десять или одиннадцать месяцев. В написании кода, который обрабатывал текст в виде косвенных блоков в файл.
Какие инструменты Вы используете для разработки и отладки BFS?
Emacs, make, и gcc.
Что было самой большой проблемой при разработке BFS?
Пытаться сделать за такой короткий срок поддержку всех функций, которые мы хотели.
Повлияла ли BFS на дизайн последующих файловых систем?
Вряд ли.
Что на сегодня представляет наибольший интерес в файловых системах?
Наибольший интерес сейчас представляют целостность и дедупликация данных. Люди также тратят много времени, пытаясь выяснить, как обеспечить надежное хранение в условиях ненадежных компонентов. RAID-5/6 это хорошо, но поскольку размер дисков увеличивается, многие люди волнуются, что отказ может возникнуть раньше, чем они проведут полную реконструкцию.
По Вашему мнению, в каком фильме, из жанра научной фантастики, показан самый лучший компьютер?
Хммм..., не уверен. Star Trek? Их компьютеры делают все и имеют интерфейс мультитач. И при обращении с ними не нужно никакого шаманства.
Axel D?rfler, разработчик Open Source BFS
Был ли у Вас опыт работы с файловыми системами до BFS?
Мне пришлось писать приложение для восстановления данных с BFS партиции жесткого диска. Это и дало все знания для, нужные мне для написания BFS.
Что было самым трудным в переписывании BFS?
Обеспечение правильной реализации B+tree, используемая в оригинальной BFS (как указано в книге Доминика) была очень неустойчивой и неэффективной.
Что было самым простым?
Реализация BFS “только для чтения” (read-only) поскольку я мог использовать большое количество кода, который я писал для восстановления данных.
Обсуждали ли Вы с Домиником BFS?
Да, но не очень подробно его недостатки, а мою реализацию.
Что бы вы изменили в BFS 2.0?
Большую часть.
Как долго Вы занимались кодингом?
Честно, я не помню. Я думаю, что только изучение заняло приблизительно недели две или около того, в то время как на написание ушло гораздо больше времени, и еще больше времени на совместимость BFS в BeOS
Какие уроки Вы получили при переписывании BFS?
При написании файловой системы, гораздо проще иметь рабочую .
И наконец, какой компьютер используете сейчас для разработки?
В зависимости от того, где я, это или ThinkPad T60, или двухгодичный Core 2 Quad со встроенной графикой от Intel.
Благодарности
Эта статья, в значительной степени, опирается на книгу Practical File System Design with the Be File System. Это редкость, что файловая система описана в таких деталях и в удобочитаемом стиле. Благодарность Axel D?rfler в проверке фактов.
Ссылки
Об авторе
Эндрю Хадсон независимый технический менеджер проектов во Флориде, США. В свое свободное время (которого у него много) он любит изучать пещеры и заниматься восстановлением антикварных автомобилей.
Журнал
Есть много причин приводящих к выводу из строя жестокого диска. Магнитный материал сектора диска может разложиться, может отказать механизм сервомотора, может отказать электроника или пользователь может перезагрузить машину в середине операции записи на диск. Если Вы достаточно долго используете свой диск, в конце концов, электроника или механика жесткого диска выйдет из строя. И, к сожалению, самое распространение явление разрушительно влияющая на файловую систему — это нетерпеливые пользователи, прерывающие работу компьютера во время операций записи файла.
Рассмотрим следующую ситуацию. Пользователь создал файл, и это — процесс сохранения его на диск. Возможно это разработчик работающий над просроченным проектом. Файловая система должна сделать несколько обновлений прежде, чем файл будет полностью сохранен. В первую очередь сохранить содержимое файла. Она должна сохранить метаданные файла, дату создания, владельца, размер файла и т.д. А также обновить суперблок. Рассмотрим что происходит при выключении питания, прежде чем операция будет завершена. В дополнении к потере Вашей работы, может быть повреждена структура данных указывающая на i-node и блоки, которых не существует. Также это может привести к невозможности загрузки файловой системы и потере других Ваших файлов.
Ведение журнала облегчает решение этих проблем. Хотя журнал и не гарантирует, что преждевременная перезагрузка не приведет к потере Вашего файла, но по крайней мере это не вызовет повреждение файловой системы.
Рассмотрим пример работы журнала. Предположим что пользователь создает новый файл и сохраняет его. Данные должны быть сохранены на диск, также должна быть сохранена новая директория с правильными метаданными. До выполнения этих дисковых операций, BFS запирает не записанные блоки в оперативную память и ведет записи в журнал файловой системы для каждого блока, который должен быть записан. После того как каждый блок успешно записывается на диск, журнал помечает запись как выполненную. Если система будет перезагружена прежде, чем блоки будут успешно сохранены, в журнале будут помечены не выполненные операции. При рестарте системы, она проверяет журнал на наличие невыполненных операций. Эти записи могут быть “переиграны” для успешного выполнения операции или может быть выполнен “откат” и операция прервется. Так или иначе, но файловая система остается в согласованном состоянии, где структура каталогов и метаданных точного соответствует данным файла.
В BFS журнал регистрирует любые изменения произведенные в каталоге, в блоке bitmap, i-node и расширенных атрибутах. Таким образом ведение журнала защищает файловую систему, но не обеспечивает возможности восстановления файлов как избыточный массив дисков или RAID.
Нет защиты от всех дисковых ошибок, BFS устойчива к преждевременным выключениям системы. Файловые системы не ведущие журнал, такие как ext2, уязвимы к несогласованности и полагаются на длительные процессы сканирования для восстановления. BFS не нуждается в сканировании дисков и Haiku может начать работу сразу после внезапного выключения.
Усовершенствования Haiku BFS в сравнении с BeOS
Версия Haiku BFS имеет ряд улучшений по сравнению с оригинальной реализацией BeOS BFS. B+tree более надежен. Haiku BFS использует кэш данных файла, в дополнении к кэшу блоков. Это привело к десятикратному увеличению скорости. POSIX atime file был убран из BeOS BFS для увеличения производительности. Haiku BFS включает оптимизированный запрос для гибридных регулярных выражений, которое позволяет смешивать статическую строку с регулярным выражением. Новые инструменты bfsinfo, bfswhich, chkindex, и recover были добавлены в Haiku BFS. Для улучшения индексации расширенных атрибутов добавлена команда reindex.
Короткое интервью с ведущим разработчиком BeOS, который работал над BFS.
(Он попросил не использовать его имени, чтобы выполнить пожелания своего нынешнего работодателя)
Как много уходит времени на написание и отладку кода от концепции до релиза?
Десять или одиннадцать месяцев. В написании кода, который обрабатывал текст в виде косвенных блоков в файл.
Какие инструменты Вы используете для разработки и отладки BFS?
Emacs, make, и gcc.
Что было самой большой проблемой при разработке BFS?
Пытаться сделать за такой короткий срок поддержку всех функций, которые мы хотели.
Повлияла ли BFS на дизайн последующих файловых систем?
Вряд ли.
Что на сегодня представляет наибольший интерес в файловых системах?
Наибольший интерес сейчас представляют целостность и дедупликация данных. Люди также тратят много времени, пытаясь выяснить, как обеспечить надежное хранение в условиях ненадежных компонентов. RAID-5/6 это хорошо, но поскольку размер дисков увеличивается, многие люди волнуются, что отказ может возникнуть раньше, чем они проведут полную реконструкцию.
По Вашему мнению, в каком фильме, из жанра научной фантастики, показан самый лучший компьютер?
Хммм..., не уверен. Star Trek? Их компьютеры делают все и имеют интерфейс мультитач. И при обращении с ними не нужно никакого шаманства.
Axel D?rfler, разработчик Open Source BFS
Был ли у Вас опыт работы с файловыми системами до BFS?
Мне пришлось писать приложение для восстановления данных с BFS партиции жесткого диска. Это и дало все знания для, нужные мне для написания BFS.
Что было самым трудным в переписывании BFS?
Обеспечение правильной реализации B+tree, используемая в оригинальной BFS (как указано в книге Доминика) была очень неустойчивой и неэффективной.
Что было самым простым?
Реализация BFS “только для чтения” (read-only) поскольку я мог использовать большое количество кода, который я писал для восстановления данных.
Обсуждали ли Вы с Домиником BFS?
Да, но не очень подробно его недостатки, а мою реализацию.
Что бы вы изменили в BFS 2.0?
Большую часть.
Как долго Вы занимались кодингом?
Честно, я не помню. Я думаю, что только изучение заняло приблизительно недели две или около того, в то время как на написание ушло гораздо больше времени, и еще больше времени на совместимость BFS в BeOS
Какие уроки Вы получили при переписывании BFS?
При написании файловой системы, гораздо проще иметь рабочую .
И наконец, какой компьютер используете сейчас для разработки?
В зависимости от того, где я, это или ThinkPad T60, или двухгодичный Core 2 Quad со встроенной графикой от Intel.
Благодарности
Эта статья, в значительной степени, опирается на книгу Practical File System Design with the Be File System. Это редкость, что файловая система описана в таких деталях и в удобочитаемом стиле. Благодарность Axel D?rfler в проверке фактов.
Ссылки
Об авторе
Эндрю Хадсон независимый технический менеджер проектов во Флориде, США. В свое свободное время (которого у него много) он любит изучать пещеры и заниматься восстановлением антикварных автомобилей.
- +11
- DuskMan
- 19 июня 2010, 20:34