LINUX.ORG.RU

Патчи для поддержки журналирования в UFS добавлены во FreeBSD-CURRENT

 ,


0

0

В основную ветку разработки FreeBSD-CURRENT (будущая основа следующего релиза FreeBSD 9.0) были внесены патчи, реализующие поддержку журналирования Soft Updates для основной файловой системы FreeBSD — UFS. Для реализации этой возможности было добавлено 11 тысяч строк кода и 2 тысячи было удалено. Максимальный размер журнала составляет 32 Мб, хранящие в себе записи о последнем миллионе операций (информация об одной операции составляет 32 байта). Спонсорами разработки являются такие крупные компании как iXsystems, Yahoo! и Juniper.

Журналирование метаданных, изменяемых при работе Soft Updates (SU+J), позволит отказаться от необходимости фонового запуска fsck после некорректного отключения файловой системы (при аппаратном сбое или отключении подачи электроэнергии, например) и достичь довольно высокой скорости восстановления состояния файловой системы при достаточно малом объеме журнала, файловая система остается полностью обратно совместимой с нежурналируемым вариантом softupdates. Для примера: процесс восстановления после экстренного отключения заполненного на 80% дискового раздела, размером 250 Гб, с использованием SU+J занял менее секунды, в то время как без SU+J обычный fsck восстанавливал целостность данных 24 (!) минуты.

Ранее журналирование для файловой системы FreeBSD реализовывалось при помощи GEOM-класса gjournal и было доступно только на уровне GEOM провайдеров. Основное отличие gjournal от SU+J в том, что первый работает на уровне блочного устройства, в то время как второй манипулирует данными только на уровне мета-данных файловой системы. Как следствие gjournal требует для хранения журнала больше памяти и уступает в быстродействии.

Новость является перепечаткой новости с сайта http://www.opennet.ru

>>> Подробности в блоге автора



Проверено: maxcom ()

Ответ на: комментарий от iZEN

> Баг вызывался командой «eject» CD-ROM'а. Эта ли не порча?

Не могу дискутировать по этому конкретному поводу. Читал, что виноват был clocksource, проблема появлялась только на конкретном железе. Слово «эпический» при этом уместно в локальном значении проблем конкретного(-ых) пользователя(-ей). Естественно, что подобные проблемы железа не всегда воспроизводимы у разработчиков, и баги просто неизбежны, но чинятся, когда есть такая возможность.

Casus ★★★★★ ()
Ответ на: комментарий от leave

ФС упасть не может — её fsck в самом скверном случае отремонтирует (даже в фоне).

Структура ФС осталась целой,

Что и требовалось от fsck.

да - нам, конечно, от этого было сильно лечге.

Обычное журналирование тоже не гарантирует сохранение пользовательских данных (c) ваш к.О.

откройте для себя data=journal

Включал? Быстро после этого работало? Будешь ещё? :))

iZEN ★★★★★ ()
Ответ на: комментарий от Casus

Если RAID рассыпался, то Ext3 будет жива, да? Где логика?

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

>Включал? Быстро после этого работало? Будешь ещё? :))

на LDAP'е включено третий год.

leave ★★★★★ ()
Ответ на: комментарий от iZEN

>Что и требовалось от fsck.

а от UFS требовалось сделать так, чтобы почта 70000 юзеров осталась на месте. с задачей она не справилась.

leave ★★★★★ ()
Ответ на: комментарий от iZEN

> Если RAID рассыпался, то Ext3 будет жива, да? Где логика?

Не будет, но от Ext3 тут ничего не зависит, рассыпется вообще любая FS.

P.S. Я начинаю расценивать подобное как тупой троллинг.

Casus ★★★★★ ()
Ответ на: комментарий от leave

На её месте и Ext3, и XFS, и JFS не справились бы — инфа 100%.

iZEN ★★★★★ ()
Ответ на: комментарий от Casus

А кто ж начал про флэшку? И кто тут дурак?

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

> А кто ж начал про флэшку?

Больная мозоль что ли?

И кто тут дурак?

Неполиткорректный вопрос. Надо спрашивать про альтернативно мыслящих.

Casus ★★★★★ ()
Ответ на: комментарий от iZEN

>На её месте и Ext3, и XFS, и JFS не справились бы — инфа 100%.

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

leave ★★★★★ ()
Ответ на: комментарий от iZEN

То есть по ссылке на барепорт RedHat, которую ты привел в качестве примера порчи ext3, такой порчи нет?

Только не говорите мне, что вы её не видите, после того, как вам на неё указали (дали две ссылки).

То есть по ссылке на RedHat порчи данных таки нет. А две ссылки ты нашел уже _после_ того, как заявил о порче данных на ext3. И эти ссылки выглядят как проблемы с железом.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Ещё раз прочти внимательно сообщения по двум близким по смыслу ссылкам. Нету там порчи железа. S.M.A.R.T. винтов чистый.

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

Ты притворяешься что-ли?

Нету там порчи железа. S.M.A.R.T. винтов чистый.

Тебе говорят о проблемах с железом, а не о SMARTе. Классический пример - южный мост нвидиевских чипсетов.

Hug37r011 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.