Pawel Dawidek опубликовал (http://groups.google.ru/group/fa.freebsd.current/msg/1efcf31...) текущие наработки проекта GJournal для FreeBSD 6.x и 7.x, инструкцию по организации журналирования данных и мета-данных UFS и результаты тестирования производительности системы.
Ниже небольшая инструкция по включению журналирования:# gjournal label /dev/ad0
# gjournal load
# newfs /dev/ad0.journal
# mount -o async,gjournal /dev/ad0.journal /mntURL: http://groups.google.ru/group/fa.freebsd.current/msg/1efcf31...
Новость: http://www.opennet.me/opennews/art.shtml?num=7752
афигеть, дайте 2. да еще независимо от файловой системы!
все, на серваках только фряха (особенно на файло-помойках).
ага, независимо. ну что за народ пошел, немощный головой. кто как не файловая система определяет какой набор изменений является транзакцией?
а там случаем не такая архитектура:* сделано что-то типа фреймворка для работы с журналом или с утсройством журнала
- апи по добавлентю поддержки этого дела для дискового устройства (био_флаш)
- апи по добавлению этого в файловую систему (транзакций)
* т.е. - говоришь, что является транзакцией для файловой системы, как обрабатывать иноды иили кааие-там самые общие структуры, и как восстанавливать. а все остальное - фор фрии. нет? поправьте, если не прав. сильно не вникал.
наверняка так. только ведь это подразумевает, что та самая "любая fs" должна это api использовать. в linux'е это сделано в виде независимого модуля jbd с самого начала, с 99 года.
fs не должна, нужен будет небольшой модультипа так:
ufs_gjournal.ko
xfs_gjournal.ko
ага. супер. и что будет делать этот ufs_gjournal.ko?
>ага. супер. и что будет делать этот ufs_gjournal.ko?Может, я жестоко ошибаюсь, но мне кажется, что дела обстоят так:
есть geom_journal.ko который расширяет geom функциями, которые позволяют как два пальца об осциллограф реализовать filesystem-specific механизм журналирования. В свете модульности самого geom, это не потребует переписывания (или патчинга) имеющегося кода для работы fs
именно, что жестоко. что толку расширять функции geom'а, если только fs знает где начинается и заканчивается транзакция? транзакция, в данном случае, это такой набор изменений, который переводит fs из одного консистентного состояние в другое консистентное состояние. пример: нужно создать файл. для этого нужно: 1) аллоцировать иноду (модифицировать суперблок и карту свободных инод); 2) инициализировать эту иноду (блок в таблице инод); 3) добавить запись в каталог (как минимум один блок каталога + инода каталога, может потребоваться аллокация дополнительного блока). как geom может знать эти подробности? так что сказки про "любую fs" и "не потребует переписывания (или патчинга)" оставьте.
> в linux'е это сделано в виде независимого модуля jbd с самого начала, с 99 года.я так понимаю, что подразумевается что разработчики фри не могли сделать это раньше,
потому что они "некомпетентные идиоты"?эта фитча нахер никому не нужна была и будет юзаться только на домашних писссюках,
на которых скорость дисков не критична, упса нет а электричество отрубается
довольно часто. на оборудовании с защитой между скоростью дисков и подождать
несколько минут раз в десятилетие я выберу таки скоростные диски.к 99 году у фри уже была устраивающая всех fs.
и сайчас эта разработка - напрасная трата времени.
очень скоро флэш-память заменит традиционные винчестеры и все ваши райзер-хуяйзер
станут историей, как флопповод на 5 дюймов.
Мдаа. Ну вы, блин, и...
>Мдаа. Ну вы, блин, и...швейк рассказал как-то поучитильную историю как один гражданин имел привычку ходить
по пивным, чокаться с каждым встречным и приговаривать "вам на нас, нам на вас".
однажды он схлопотал по чайнику и в процессе выяснилось, что он имел в виду
"вам на нас, нам на вас нечего сердиться!"поэтому, - поучал швейк, - нужно стараться выражать свои мысли яснее.
бла-бла-бла. никому эта фича на bsd не нужна, очевидно. потому как работает bsd только на домашних писюках. у всех остальных, кто хоть как-то связан с реальными приложениями масштаба предприятия (sgi/dec/m$/sun/etc) - давно есть журналирование.
что то вроде ext2/ext3 выходит
Радует, что это GEOM, а не хрень какая-нибудь :)
видимо всетаки почитали сурсы солярки, бо там уже давно к уфс журналирование прикрутили )))))))
ага. иначе не умеют.
Кто-нибудь из вас прочитал сообщение pjd@ ? Похоже что нет.
ну раз вы прочитали, расскажите всем нам в каком там месте транзакции описываются.
Every few seconds (you may define how many) journal is terminated and
marked as consistent and gjournal starts to copy data from it to the
data provider. In the same time new data are stored in new journal.
Let's call the moment in which journal is terminated as "journal switch".
Journal switch looks as follows:
1. Start journal switch if we have timeout or if we run out of cache.
Don't perform journal switch if there were no write requests.
2. If we have file system, synchronize it.
3. Mark file system as clean.
4. Block all write requests to the file system.
5. Terminate the journal.
6. Eventually wait if copying of the previous journal is not yet
finished.
7. Send BIO_FLUSH request (if the given provider supports it).
8. Mark new journal position on the journal provider.
9. Unblock write requests.
10. Start copying data from the terminated journal to the data provider.
ага. покажите где здесь "транзакция". или уважаемый автор предлагает "терминировать" журнал посередине какой-нить creat(2) или rename(2) ?
2. If we have file system, synchronize it.
3. Mark file system as clean.
4. Block all write requests to the file system.
5. Terminate the journal.Посередине, да, ага. А как же!
>2. If we have file system, synchronize it.
>3. Mark file system as clean.
>4. Block all write requests to the file system.
>5. Terminate the journal.
>
>Посередине, да, ага. А как же!Такой подход даст производительность на уровне ext3 с включением журнализирования данных. Причем на любой FS. Т.к. нативные механизмы FS не используются.
Такой подход даст ЮФС журналирование.Не думаю, чтобы падение производительности оказалось заметным.
ну да, ну да. двойная запись _всего_ в разные участки диска конечно же не окажет заметного воздействия на производительность. "серверная os" ...
Еще как даст. Единственная FS которая под linux журнализирует данные а не метаданные это ext3. И по умолчанию включено журнализирование метаданных. Включение журнализации еще и данных дает падение производительности. Когда тестировали ext3 с таким флагом это было заметно.
не нужно лжи. по-умолчанию ext3 работает в ordered mode. это означает, что журналируются только метаданные, а данные принудительно сбрасываются перед каждой транзакцией.
Читать сообщение, на которое отвечаешь, нынче не модно? Там ровно это и написано - что по умолчанию на ext3 журналирование метаданных, а включение журналирования данных приводит к падению производительности.
>не нужно лжи. по-умолчанию ext3 работает в ordered mode. это означает, что
>журналируются только метаданные, а данные принудительно сбрасываются перед каждой транзакцией.
Для тех кто не читает. Я указал что по умолчанию журнализируются метаданные. Читайте внимательнее.
LOL. ну и где здесь декларация начала-конца транзакции в ufs? как этот доморощеный gjournal узнает когда все текущие операции завершены? я уже не говорю о том, что нет возможности выбрать режим журналирования writeback/data/ordered, что на время терминирования журнала (читай сброса на диск) заблокированы любые модификации и так далее. децкая поделка.
Ключевые слова: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.
таки придется что-то в ufs менять? ай-яй-яй ... как уже было сказано, журналирование данных - это вещь тормозная по определению. об чем сам автор и написал. так что давайте там, не изобретайте велосипед с квадратными колесами.
Мдя... в результате получаем туже производительность что у ext3. Причем в не зависимости от файловой системы. Будь то XFS ReiserFS или любая другая. Ганс вон хочет чтобы его reiserfs с отдельными плагинами в ядро включили. А тут все раз-раз и в дамках одно слово офигеть.
непонял. вообще то во фре есть алтернаимва журналированию - soft updates.
нафиг вообще нужно это журналирование
это не альтернатива, это костыль. SU не спасают от необходимости запуска fsck. fsck хорошо нагружает диск. система, соответственно, тормозит. когда у вас терабайтная fs, fsck будет работать очень долго и система тоже будет долго тормозить. воостановление через журнал - это максимум несколько секунд, независимо от размера fs.
Не знаю на каких у вас там дисках очень долго всё запускается, а у меня на 4х400Gb RAID5 (файлсервер с папкой обмена и интенсивной записью более 50 клиентов одновременно) после внезапного выключения и повторного включения поднимается довольно быстро, пять минут не решают, если пользователи уже заметили отсутствие услуги.А по мне так вообще нахрен этот журнал не нужен, на всех серверах стоит софт, который корректно заглушит и машину и бесперебойник в случае пропажи электричества.
Более того, на машинах с дисковыми контроллерами с кешами по 128 Мбайт и отсутствием аккумулятора для его подпитки, фатальность потери данных из кеша с наложением журналирования достаточно серьезная вещь, боюсь что после этого журнал уже будет бесполезен.
ага, безумно огромная fs - 1,2TB. вашим пользователям может и пол-часа не решают.
только не у всех же такие безденежные пользователи ;)ну да, видели мы на M9 супернадежную систему обеспечения питанием, которая накернулась
с пропажей питания. и да, конечно, у вас-то этого никогда не случится. куда там какой-то M9
до вас ...про кэш на контроллере - это вы глупость сказали. нормальный контроллер понимает штуки
типа ordered tag и так далее.
про нормальный контроллер - это вы глупость сказали.
потому что нормальный контроллер сортирует сектора в порядке их расположения на диске перед записью
а разве fsck на фре работает не в фоне? или я ошибаюсь
вот на линуксе я ощущаю работу fsck при старте- это точно
>а разве fsck на фре работает не в фоне? или я ошибаюсь
>вот на линуксе я ощущаю работу fsck при старте- это точнозапуск на фоне - тоже никому не нужная фитча, которую сделали в 5.x
fsck на фоне грузит винт так, что остальные приложения не могут нормально
работать. в итоге всё равно приходиться ждать, и ждать гораздо дольше, т.к.
ось не в однопользовательском режиме. а если прикладная прога поюзает
кривые иноды раньше fsck?я давно рамечаю винт одним девайсом и не парюсь.
один единственный раз fsck не справился с работой и я почекал фс с флоппика.
лучше я буду уверенным, что приложения работают на чистой fs.я тоже не в восторге, когда приходиться юзать рыбий жир.
Пока не fsck - НЕ загрузится.
> Пока не fsck - НЕ загрузится.да не нужет он загруженный без fsck. всё равно тормозит и толком не работает.
пусть почекается и загружается нормально. раз в году авария такая бывает, 5 минут
в лом подождать?раз по дефолту журналирование данных на ext3 не включено, значит его никто и не юзает.
больше разговоров. не нужная это фитча, просто, наверное, достали ламмеры своими
"а вот у вас fs не журналируемая". ну так нате, вот теперь журналируемая.
только никто это юзать не будет.крутая технология, fs чекать каждые несколько секунд. прямо фонтан гениальных идей.
купи упса и не парься.
гыгыгы. по умолчанию ext3 журналирует _метаданные_, чего достаточно для обхода fsck.
а ваше "журналирование" всего в ufs - это да, нафиг такое поделие.ups не решает проблему полностью. просто потому, что ядро может накернуться. вследствии
ошибок железа, драйверов или просто ядра. понятно, что у freebsd такого не бывает ;)
>гыгыгы. по умолчанию ext3 журналирует _метаданные_, чего достаточно для обхода fsck.если почитаешь выше, то увидишь, что это уже обсуждалось
>а ваше "журналирование" всего в ufs - это да, нафиг такое поделие.
если бы была реальная производственная необходимость, эту работу выполнили бы полтора
десятилетия назад. не надо никому.
в desktop/pc-bsd может и включат по дефолту, там как раз будет.
в любом случае работа выполнена на высоком профессиональном уровне, не то что у некоторых>ups не решает проблему полностью. просто потому, что ядро может накернуться. вследствии
>ошибок железа, драйверов или просто ядра. понятно, что у freebsd такого не
>бывает ;)бывает, но fsck замечательно справляется со своей работой.
и бывает такое раз в десятилетие, несколько минут можно и подождать.
не нужно отсылать меня к каким-то там обсуждениям -- я умею читать маны.в качесте _замены_ журналированию, в freebsd сделали SU + background fsck.
только вот недалекие люди оказались, bsd'шные разработчики - видимо поленились
поглядеть какими темпами растет емкость дисков и сколько времени будет кушать
fsck на fs размером в десятки-сотни TB.про высокий профессиональный уровень советую вам помолчать. ибо поделию этому,
выполненному на уровне geom, еще ползти и ползти до jbd в linux, который
умеет журналировать метаданные, а не все подряд. ну я понимаю, конечно, что
freebsd не предназначена для хорошей производительности I/O (положим несколько
сотен MB/s), поэтому и это корявое поделие в geom "сойдет". как и доисторический
vfs, в котором два параллельных rename'а могут попортить консистентость fs.да-да, замечательно. дайте только ему несколько часов. или у вас в bsd world
никто не слышал про массивы размером в сотни TB?PS. как много я узнал о bsd people :)
Собственно, зачем для UFS2 журналирование? Неужели чего-то в ней не хватает? Просто интересная разработка с ограниченным кругом применений.
> зачем для UFS2 журналирование?
Просто к примеру в случае аварийного reboot'а сервера сильно ускорится проверка разделов.
А за это стоит поборотся.
Русский перевод http://wiki.bsdportal.ru/doc:gr_gjournal
вообще-то команда фрибзди не всегда верно выбирает путь развития. совершенно дебильно,
например, они разнесли базовую ось и пакаджи на разные диски. ни разу в жизни (юзаю юздю
с 99 года) не пользовался LiveCD. всегда сливал один диск, теперь надо сливать два.
не говоря уже о сценарии, который теперь просит несколько раз поменять эти диски в
процессе установки пакаджа.я сам программист и хорошо понимаю, что интерес человека к какой-то области очень часто
перевешивает реальную полезность и нужность данной работы если работа не направляется
твёрдой рукой технически грамотного руководителя.совершенно не согласен с тем, что нежурналируемая fs была "ахилесовой пятой".
эта работа - напрасная трата драгоценного времени высококвалифицированого специалиста.
ну да, вся freebsd - напрасная трата времени. ясное дело, что нет ничего правильнее fsck на терабайтных fs.
>вообще-то команда фрибзди не всегда верно выбирает путь развития. совершенно дебильно,
>например, они разнесли базовую ось и пакаджи на разные диски. ни разу
>в жизни (юзаю юздю
>с 99 года) не пользовался LiveCD. всегда сливал один диск, теперь надо
>сливать два.
>не говоря уже о сценарии, который теперь просит несколько раз поменять эти
>диски в
>процессе установки пакаджа.Это связано с тем что 99% пользователей фряхи не пользуются пакэйджами, а вам было лень элементарно открыть хэндбук и прочитать про систему портов. Пакэйджи в дистрибутивах BSD содержат безумно устаревший софт, и чем дальше, тем более устаревающий. Т.е. не команда фрибзди дибильно что-то делает, а вам надо меньше авторитетно высказывать мнение и больше изучать возможности команды man.
1) Вообще то это глупость - ставить при инсталляции кучу package. (Вы же соврем не видите комментарии, которые появляются после установки большинства пакетов! - они полезны!) Правильный Вариант (и во FreeBSD и в Linux) иметь каталог (DVD-диск), где все нужные пакеты (rpm-ки, дистфайлы) находятся в одном месте. Если в Debian 11 CD, и мы ставим очень много сразу, диски тоже менять будем...2) Если Вы сливаете из Интернета диски (есть возможность), то кто Вам мешает пользоваться портами? Слили мини-инсталляцию, поставили минимум + порты и вперед! И по трафику выйдет меньше в разы (чем скачивать 2 CD).
3) Логика программистов меня всегда поражала :)
> 1) Вообще то это глупость - ставить при инсталляции кучу package. (Выне учи отца ибаца. геммарой происходил при установке кде для 5.3 (сейчас может исправили)
я как раз из тех, кто долго и вдумчиво выбирает, чего не надо ставить.
в итоге кде требуется куча всягой требухи и от просит диск номер один
несколько раз.
в итоге я стал ставить кде из портов. длго, ну и хснм, это не каждый день делается> 2) Если Вы сливаете из Интернета диски (есть возможность), то кто Вам
> мешает пользоваться портами? Слили мини-инсталляцию, поставили минимум + порты и вперед!скорость, мля! кде на целероне 1,7 собирался 3 дня.
я утром прихожу, а там дебильный вопрос с дебильным меню дебильного цвета а-ля нортон
коммандир. какой идиот это придумал? хоть бы переменную определили USE_DEFAULT=yes> 3) Логика программистов меня всегда поражала :)
а, так ты ещё и не программист. тогда понятно, ты гораздо умнее остальных.
>скорость, мля! кде на целероне 1,7 собирался 3 дня.
>я утром прихожу, а там дебильный вопрос с дебильным меню дебильного цвета
>а-ля нортон
>коммандир. какой идиот это придумал? хоть бы переменную определили USE_DEFAULT=yes
Там "нормальный вопрос, нормального цвета". Мне, например, нравится. И DEFAULT=yes тоже там есть - нада уметь пользоватся, а не обзывать всех подряд непристойными выражениями. Стыдно, товарисч.
> Там "нормальный вопрос, нормального цвета". Мне, например, нравится. И DEFAULT=yes тожену да, должен быть, это я сейчас соображаю, а тогда не посмотрел
> есть - нада уметь пользоватся, а не обзывать всех подряд непристойными
> выражениями. Стыдно, товарисч.а кого конкретно я обзываю? я так, про всех, никого лично.
а цвета нортон коммандира мне не нравятся как класс.
чёрно-зелёная консоль рулез форева.
>скорость, мля! кде на целероне 1,7 собирался 3 дня.Открой для себя ключи команды make. man make
>я утром прихожу, а там дебильный вопрос с дебильным меню дебильного цвета
>а-ля нортон
>коммандир. какой идиот это придумал? хоть бы переменную определили USE_DEFAULT=yesЕсть там эта переменная, определяется в /etc/make.conf. Хоть для всех портов, хоть для конкретного специально.
>> 3) Логика программистов меня всегда поражала :)
>а, так ты ещё и не программист. тогда понятно, ты гораздо умнее
>остальных.Ну ты-то точно не программист. Программисты умеют читать документацию, а не только писать.
Без комментариев...