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 ()
Последнее исправление: annoynimous (всего исправлений: 2)
Ответ на: комментарий от alex-w

> данные на хваленых супернадежных журналируемых файлухах на линуксе уже дважды терял.

Подсказываю: журналирование не предназначено, в общем случае, для сохранения целостностни данных. Когда идёт речь о журналировании мета-данных, которых абсолютное большинство, то говорят, о непротиворечивом состоянии метаданных файловой системы, а не о данных в файлах.

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

> ext3 в режиме journal гарантирует целостность данных.

Речь идёт о journal=data, я так понимаю. Что используют совсем не часто, часто просто journal=ordered, тогда журналируются только мета-данные.

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

Quote:

ечь идёт о journal=data, я так понимаю. Что используют совсем не часто, часто просто journal=ordered, тогда журналируются только мета-данные.

Да о нём, только правильно data=journal / data=ordered / data=writeback =)

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

> Да о нём, только правильно data=journal / data=ordered / data=writeback =)

Я Ext3 не пользуюсь, не помню все ключи ;) Но смысл не меняется, при журналировании метаданных не стоит ожидать целостности данных.

Casus ★★★★★
()

новость один в один как на опеннет. признайся туда ты тоже это запостил или просто тупо скопировал без указания оригинального сайта?

awesome
()
Ответ на: комментарий от madgnu

>Ну где изен-то?!

толсто потроллил и лопнул.

//тесты производительности где?

devl547 ★★★★★
()
Ответ на: комментарий от no-dashi

>А если продолжать ряд в соответствии с реальными возможностями каждой из систем, то круче миникса только MS-DOS и CP/M? :-)

Круче minixа gnu/hurd, а DOS и CP/M были вполне рабочими OS для своих компьютеров.

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

> таки история показывает, что журнал нужен! а все ...ны кричали нафик несдался

Журнал нужен для БЫСТРОГО восстановления файловой системы.

А то, что fsck_ffs до этого момента работала в ФОНЕ всего 24 минуты на 250ГБ разделе — это автор упустил указать. На такое не способна даже Ext4, не говоря уж о других недо-ФС в линаксе, которые нельзя проверить, предварительно не отмонтировав том.

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

На OpenNet.ru вчера высказался:

Вот у меня сейчас запущен десктоп Xfce4 4.6.1, Firefox 3.6.3, Thunderbird 3.0.4 и... RSSOwl 1.2.3.

В фоне из исходников компилируется система (FreeBSD 8.0-STABLE).

Память: занято 1,3ГБ (33,5%) из 3,9ГБ. Подкачка: 0 байт (0,0%) из 4ГБ.

ZFSv14 ONLY.

Тормозов GUI и завихрений звуковоспроизведения, какие случаются в Linux Ubuntu, не ощущаю вообще.

Зачем мне повторяться?

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

alex-w> Я тоже так думал раньше. Пока не нарвался на ситуацию, когда на ext3 с журналом данные накрылись


Данные могут накрыться на любой ФС. UFS - не исключение.

P.S.

У меня вот несколько раз были внезапные перезагрузки из-за перебоя электроэнергии - на ext3 никакие данные потеряны не были.

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

>На OpenNet.ru вчера высказался:

Зачем мне повторяться?

У меня Gentoo, доктор, тоже компилю, тоже не тормозит. Это плохо, да? Это лечится?

Может не стоит мнить BSD-системы центром Вселенной? Они конечно круты и тоже нужны. Но не одними ими едины...

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

никто не мнит BSD центром вселенной, не стоит всех по этому виндузятнику равнять.

x4DA ★★★★★
()

Убийственная новость. Даже язвить не хочется.

ttnl ★★★★★
()

Вау! Круто! А в ядро патч спортируют или долго ждать придётся?

Hug37r011
()
Ответ на: комментарий от madgnu

>>Тормозов GUI и завихрений звуковоспроизведения, какие случаются в Linux Ubuntu

ржали всем офесом

Со звуком в бубунте 9.04 и 9.10 действительно такая проблема имеется. но это из-за поломанного планировщика в ядре. А поломан он кривой сборкой ядра. Но то что в убунте - не значит что в других дистрах.

Хотя чему удивляться, у меня сложилось впечатление что достопочтимые фрюшники только через PuTTY видели линух, и то запущенный через виртуальную машину во фряхе. Потому вероятнее всего что 90% заявленных фрюшнегами глюков - проблемы кривой виртуализации во фре.

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

>говоря уж о других недо-ФС в линаксе, которые нельзя проверить, редварительно не отмонтировав том.

Это какие такие недо-ФС в каком таком линаксе? В линуксе можно перемонтировать раздел в режиме RO и проверять наздоровье. Запрет на проверку раздела, смонтированного на запись, абсолютно логичен для многозадачной многопользовательской ОС.

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

Это какие такие недо-ФС в каком таком линаксе?

Все, что есть в продакшене.

В линуксе можно перемонтировать раздел в режиме RO и проверять наздоровье.

fsck будет в этом случае ремонтировать ФС или только говорить, что всё плёхо?

Запрет на проверку раздела, смонтированного на запись, абсолютно логичен для многозадачной многопользовательской ОС.

C 2003 года, когда появилась UFS2, — уже нелогичен. Все современные ФС допускают проверку в онлайне безе перемонтирований. Линакс остаётся тормозить на барахле, родом из XX века («подождите, сейчас дискетку отформатирую» (с) анекдот).

iZEN ★★★★★
()

бздишники жмуться как старые девственницы.

и журнал прикрутить и не дай бог, чтоб никто не подумал, что они это сделали.

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

> Ну что? Слились со своим геомом? То орали, что GEOM - гибкое и эффективное средство. Оказалось - пук и ничего больше.

GEOM остался гибким и эффективным средством. 3й абзац не дочитал, да? Сразу вопиющий пост побежал строчить.

PS: данные терял на reiser-е, а на ext3 не было пока (правда пару раз fsck не прошел, пришлось в сингл-мод идти).

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

> > В линуксе можно перемонтировать раздел в режиме RO и проверять наздоровье.

fsck будет в этом случае ремонтировать ФС или только говорить, что всё плёхо?

Починит все что ремонтопригодно

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

>fsck будет в этом случае ремонтировать ФС или только говорить, что всё плёхо?

Будет чинить.

C 2003 года, когда появилась UFS2, — уже нелогичен. Все современные ФС допускают проверку в онлайне безе перемонтирований. Линакс остаётся тормозить на барахле, родом из XX века («подождите, сейчас дискетку отформатирую» (с) анекдот).

Нелогичен для бзды, где от выдёргивания флэшки ось виснет.

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

Так разница только в скорости восстановления при отказах. При штатной работе простого SU вполне достаточно.

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

>Все современные ФС допускают проверку в онлайне безе перемонтирований.

дадада, я помню, как у нас в 2007 году UFS2 упала намертво при fsck на активно используемом rw-разделе с почтой (2Тб maildir'ов).

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

>> Это какие такие недо-ФС в каком таком линаксе?

Все, что есть в продакшене.

Это звучит просто глупо. Какой ещё продакшен? Если уж стали говорить о Линуксе, так потрудитесь выбирать выражения. Если не в курсе, то у ядра есть версии, а вот какие версии и с какими доработками используют в «продакшене» различные устройства различных фирм - это сугубо их личное дело. Если-же вы имеете в виду «продакшен» той фирмы, в которой работаете, то можно хотя-бы список фс и версий ядра соответственно?

P.S. mount -o remount,ro поможет при склерозе

Hug37r011
()

а в -STABLE оно когда появится известно?

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

данные могут накрытся совершенно свободно например ты сделал write() без fsync() и выдернул питалово. И твои мега данные благополучно пропали так как транзакция еще не была закрыта (и закроется только через 5 секунд)

Но правда состоит в том что 99.99% надежного журналирования без fsync не существует ни у linux ни у freebsd ни у windows(про мак я вообще молчу)

А насчет сабжа: Прогматическая идея жирналирования победила классную но катастрофически сложную идею soft-updates в конкретных деталях которой разбирался только автор(McKusic). Для тех кто не верит пусть возмет книгу по CS и заглянет в главу топологическая сортировка на циклическом графе.

-dmonakhov

anonymous
()
Ответ на: комментарий от NekoExMachina

А вот тормоза чтения/записи - вижу.

Я измерял скорость записи на зеркало GMirror под UFS2 и зеракало в пуле ZFS. Выводы утешительные: на UFS2 запись происходила быстрее, чем на ZFS, всего лишь на ~12%.

Можешь включить ZFS prefetch:

% echo "vfs.zfs.prefetch_disable=0" >> /boot/loader.conf

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

дадада, я помню, как у нас в 2007 году UFS2 упала намертво при fsck на активно используемом rw-разделе с почтой (2Тб maildir'ов).

При отключенных Soft Updates и не такое случается. :))

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

> Нелогичен для бзды, где от выдёргивания флэшки ось виснет.

А у линакса портится корневая файловая система (Ext3, журналируемая) при случайном выдвижении лотка CD-ROM'а: https://bugzilla.redhat.com/show_bug.cgi?id=468027

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

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

> А у линакса портится корневая файловая система (Ext3, журналируемая) при случайном выдвижении лотка CD-ROM'а: https://bugzilla.redhat.com/show_bug.cgi?id=468027

Покажешь сообщение, в котором говорится о порче ФС?

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

Reported:    2008-10-22 09:57 EDT by Nate Golnik
Modified:    2010-02-17 04:09 EST (History)
CC List:    33 users
Эпично.

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

На самом деле, крайне странно. smartmontools ничего в mail плохого не отправляли, а bios при загрузке сообщил, что hdd smart status: bad; backup and replace.

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

А у линакса портится корневая файловая система (Ext3, журналируемая) при случайном выдвижении лотка CD-ROM'а: https://bugzilla.redhat.com/show_bug.cgi?id=468027

Покажешь сообщение, в котором говорится о порче ФС?

Здесь и там.

То есть по ссылке на барепорт RedHat, которую ты привел в качестве примера порчи ext3, такой порчи нет? Та ты еще и лжец, Изя.

И кстати... оба бага из твоего второго сообщения зарепортил один человек, что как бы намекает.

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

>А это не из NetBSD взято-ли?

Там вроде бы давно реализовали softups.


Наоборот, SU попали в NetBSD из FreeBSD. А журналирование NetBSD подарила какая-то Wasabi Systems. Оно было реализовано независимо от SU.

morbo
()
Ответ на: комментарий от anonymous

>Прогматическая идея жирналирования победила классную но катастрофически сложную идею soft-updates в конкретных деталях которой разбирался только автор(McKusic). Для тех кто не верит пусть возмет книгу по CS и заглянет в главу топологическая сортировка на циклическом графе.

Идея журналирования не победила, а органично дополнила идею SU. Благодаря SU объём журнала и, соответственно, временные издержки на журналирование значительно меньше, чем у классического журналирования.

morbo
()
Ответ на: комментарий от Quasar

>Ну что? Слились со своим геомом? То орали, что GEOM - гибкое и эффективное средство. Оказалось - пук и ничего больше.

И всё-таки GEOM - эффективное средство, раз позволяет делать журналирование блочных устройств. Да и не только журналирование, там много чего есть: зеркалирование, чередование, различные варианты RAID, экспорт диска в сеть, шифрование, сжатые диски. Для реализации всего этого не нужно ковырять тонны кода, достаточно написать ещё один модуль.

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

ФС упасть не может — её fsck в самом скверном случае отремонтирует (даже в фоне). А вот файлы даже при журналировании транзакций не спасутся — останутся ошмётки из блоков данных, которые fsck, в случае UFS2, будет планомерно освобождать, если запущена с ключом "-y", а какие посчитает связанными частями файлов, переместит в каталог /lost+found. Там вы их и найдёте.

man fsck_ffs(8)

Orphaned files and directories (allocated but unreferenced) are, with the operator's concurrence, reconnected by placing them in the lost+found directory. The name assigned is the inode number.

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

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

По двум ссылкам у человека рассыпался RAID ДВА_РАЗА и всё добро на Ext3 в результате эпичного бага в ядре. Баг вызывался командой «eject» CD-ROM'а. Эта ли не порча?

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

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

> ФС упасть не может

ню-ню. свистите дальше, у вас хорошо получается

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

У одного и того же человека, прошу заметить, на одном и том же железе. У вас есть гарантии, что это не какой-то особо альтернативный IDE-контроллер? У людей ext3 годами работает в рейдах, без рейдов, и все не рассыпается.

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

Ты не понял меня, защитник братьев меньших (с). fsck на rw разделе, в который в этот момент шла активная запись, угробил нас 2Тб почты. Да, наша вина, что не в сингле чинили - время поджимало. Структура ФС осталась целой, да - нам, конечно, от этого было сильно лечге.

А вот файлы даже при журналировании транзакций не спасутся — останутся ошмётки из блоков данных

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

которые fsck, в случае UFS2, будет планомерно освобождать, если запущена с ключом "-y", а какие посчитает связанными частями файлов, переместит в каталог /lost+found. Там вы их и найдёте.

Несомненно, восстанавливать 2Тб мелких файлов из /lost+found - это именно то, о чем я мечтал всю жизнь.

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