Журналирование UFS в FreeBSD

>Нехватка журналируемой файловой системы была ахиллесовой пятой FreeBSD много лет.

Ах вот оно что, а я то думал линуксу уже изза BSD настает ***дец!

Поздравляю BSD :)))

Это юмор?

Нет, это GEOM модуль, для добавления поддержки функций журналирования в любую файловую систему, которой это потребуется:

GJournal was designed to journal GEOM providers, so it actually works below file system layer, but it has hooks which allow to work with file systems. In other words, gjournal is not file system-depended, it can work probably with any file system with minimum knowledge about it.

>..в любую файловую систему..

"..вероятно МОЖЕТ работать с любой файловой системой.."

Очень интересно, почему автор gjournal нескоординировал усилия с Ivan Voras, цель то была одна?

gjournal over geli over ufs? :) бесмыслица какая-то...

это наверное шутка! ну неужели! блин....ураааа!!!

Интересно, что изменил anonimous_incognito в тексте новости???? Строку: "Теперь в UFS появилось журналирование"???

Также интересно, почему бздуны не могут форкнуть какую-нибудь журналируемую FS и прикрутить её к ядру, если никак не осилят UFS-журнал???

Не, там ссылка на сайт бздунов была(bsdportal.ru), вот ее он и удалил.Не, там ссылка на сайт бздунов была(bsdportal.ru), вот ее он и удалил.

форкануть то можно, но лицензии разные.

Кстати, хотел обратить ваше внимание, правильно что анонимусы так критичны ко всему что происходит в мире BSD,

это недает опустить руки энтузиастам, они ведь лучше вашего понимают, что вы сами недаете остаться равнодушными...

FreeBSD never Die, почему? да потому что это система реализованная свободными людьми, и так будет всегда...

История Linux начиналась очень похоже... но маркетинг-херкетинг загонит его в могилу.

>..если никак не осилят UFS-журнал???

а ты правда думаешь что панацея от надуманных тобой проблем?

SU альтернативный способ обеспечить непротиворечивость данных.

В FreeBSD проблемы не с FS, а с методами доступа к storage device, это в свою очередь было сделано тоже не без причины,

небудучи человеком сведущим в делах FreeBSD ты хер когда догадаешся зачем... =]

В самом деле чтоль.. Ладно... глянем на выходных..

>SU альтернативный способ обеспечить непротиворечивость данных.

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

>Также интересно, почему бздуны не могут форкнуть какую-нибудь >журналируемую FS и прикрутить её к ядру, если никак не осилят UFS-журнал???

Ничего под не BSD лицензией в ядре. А все ФС под GPL, правда есть zfs и ufs с журналированием в OpenSolaris, но насколько совместима BSD и лицензия OpenSolaris я не знаю?

> Ничего под не BSD лицензией в ядре. А все ФС под GPL

а по спекам написать?

а UFS2 была разве не журналируемой?

> Нехватка журналируемой файловой системы была ахиллесовой пятой FreeBSD много лет.

Странно, а сами BSDшники кричали, что она им не нужна... Что-то изменилось?

>Ничего под не BSD лицензией в ядре. А все ФС под GPL, правда есть zfs и ufs с журналированием в OpenSolaris, но насколько совместима BSD и лицензия OpenSolaris я не знаю?

Насколько я понимаю, несовместима.

BSD выгодно пиарить только проприетарщикам, которые на них бачи зашибают и спасибо не говорят.

>>Ничего под не BSD лицензией в ядре. А все ФС под GPL, правда есть zfs и ufs с журналированием в OpenSolaris, но насколько совместима BSD и лицензия OpenSolaris я не знаю?

>Насколько я понимаю, несовместима.

вот выйдет OpenSolaris под GPLv3 - во будет смеху :)

http://www.opennet.ru/opennews/art.shtml?num=7744

Andrey V. Elsukov опубликовал патч, добавляющий в DHCP клиент FreeBSD поддержку RFC 3442.

а как обстоят дела с этим в Linux ?

Патч поддержки RFC 3442 в DHCP клиенте F, MaDMaN, 22:48:18, 19/06/2006 [ответить] (10) Когда же это будет в линуксе??? А то эту проблему обхожу через задний проход...

на улице НетБСД теж праздник: импортировали блютуц

а dhclient в линуксе разве не такойже как во фре?

>а по спекам написать?

это несколько человеко-лет,
они хотят, но пока не могут.

>http://www.opennet.ru/opennews/art.shtml?num=7744

Andrey V. Elsukov опубликовал патч, добавляющий в DHCP клиент FreeBSD поддержку RFC 3442.

а как обстоят дела с этим в Linux ?

Патч поддержки RFC 3442 в DHCP клиенте F, MaDMaN, 22:48:18, 19/06/2006 [ответить] (10) Когда же это будет в линуксе??? А то эту проблему обхожу через задний проход...

1. О маршрутах должен знать маршрутизатор, а не рабочая станция. 2. Патч опубликован но не принят.

>а UFS2 была разве не журналируемой?

нет конечно, каким боком?

в *BSD пока нет журналируемых фс.

>Странно, а сами BSDшники кричали, что она им не нужна...

ну не знаю, много раз поднимался вопрос о том чтобы портировать(переписать)
xfs/jfs/reiser4, и все говорили, да это было бы неплохо,
и даже на sf.net есть несколько проектов,
но люди оценив затраты сворачивали свою дейтельность.

Выглядит не очень, по времени регрессия почти два раза,
только в одном случае выигрыш, и я думаю это скорее всего за счет отложенной записи. Может стоит все-таки более тесно интегрировать фс и журнал, например как в Solaris

Хватит флеймить тем, кто не знает о чем пишет!!!

Soft updates рулит.

>Soft updates рулит.

а что случится если дисков много, и проверяя в фоне один из
них fsck натолкнется на сбойный сектор?

вообще-то soft updates и background fsck это две разные вещи

Полезная штука. Для desktop. Смысла в использовании журналируемых FS (да и навесных журналов) на серверах не вижу аж никакого.. Если может исчезнуть питание - значит это уже не сервер. Точнее - не тот сервер, сохранность данных на котором критична.

>Полезная штука. Для desktop. Смысла в использовании журналируемых FS (да и навесных журналов) на серверах не вижу аж никакого.. Если может исчезнуть питание - значит это уже не сервер. Точнее - не тот сервер, сохранность данных на котором критична.

Т.е., например, КЗ в ИБП или БП не может быть в принципе? Ну-ну.

> Т.е., например, КЗ в ИБП или БП не может быть в принципе? Ну-ну.

Случится может всё что угодно. Только дело всё в том, что для нормальной production-grade системы выход из строя одного сервера практически не сказывается на функционировании системы в целом. Да и площадки/железо выбираются из принципа надёжности а не дешевизны.

Нужно просто реально оценивать в какую сумму вам может обойтись downtime. Для серьёзных систем эта цифра в несколько раз перекрывает дополнительные расходы на нормальное железо.

В общем согласен - утверждение что "журналирование только для десктопов" слишком ультимативно. Скажем так - для десктопов и lower-class проектов, где стоимость downtime меньше дополнительных расходов на организацию надёжной работы всей системы.

>Т.е., например, КЗ в ИБП или БП не может быть в принципе? Ну-ну.

В нормальных серверах блоков питания - минимум две штуки; питаются от независимых источников бесперебойного питания.

То есть, останов сервер а по питанию может произойти, но вероятность эта сама по себе очень невелика. Но даже это не особо важно, потому, что серьезные проекты не делаются без дублирования.

Тем не менее, журналируемая ФС - это полезная вещь и хорошо, что она теперь есть во FreeBSD. И разумеется, можно не использовать журнал, если он не нужен.

>Странно, а сами BSDшники кричали, что она им не нужна... Что-то изменилось?

Потому и сделали так - журналирование всех данных целиком независимо от ФС. Для только метаданных на UFS и soft-updates неплохо справляются.

Кроме сохранения непротиворечивости состояния файловой системы, журнал так же увеличивает быстродействие при массивных изменениях.

>Для только метаданных на UFS и soft-updates неплохо справляются.

UFS - тормоз.

>Soft updates рулит.

Тогда почему их больше нигде не используют?

>>Soft updates рулит.

>Тогда почему их больше нигде не используют?

А почему виндовс больше нигде не используют?