| 1.1, leonardinius (ok), 17:03, 20/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
афигеть, дайте 2. да еще независимо от файловой системы!
все, на серваках только фряха (особенно на файло-помойках). | | |
| |
| 2.3, Аноним (3), 17:32, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
ага, независимо. ну что за народ пошел, немощный головой. кто как не файловая система определяет какой набор изменений является транзакцией? | | |
| |
| 3.4, leonardinius (ok), 17:42, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
а там случаем не такая архитектура:
* сделано что-то типа фреймворка для работы с журналом или с утсройством журнала
- апи по добавлентю поддержки этого дела для дискового устройства (био_флаш)
- апи по добавлению этого в файловую систему (транзакций)
* т.е. - говоришь, что является транзакцией для файловой системы, как обрабатывать иноды иили кааие-там самые общие структуры, и как восстанавливать. а все остальное - фор фрии. нет? поправьте, если не прав. сильно не вникал. | | |
| |
| 4.5, Аноним (3), 17:52, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
наверняка так. только ведь это подразумевает, что та самая "любая fs" должна это api использовать. в linux'е это сделано в виде независимого модуля jbd с самого начала, с 99 года. | | |
| |
| 5.6, kruk (?), 18:58, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
fs не должна, нужен будет небольшой модуль
типа так:
ufs_gjournal.ko
xfs_gjournal.ko | | |
| |
| |
| 7.11, kruk (?), 19:38, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>ага. супер. и что будет делать этот ufs_gjournal.ko?
Может, я жестоко ошибаюсь, но мне кажется, что дела обстоят так:
есть geom_journal.ko который расширяет geom функциями, которые позволяют как два пальца об осциллограф реализовать filesystem-specific механизм журналирования. В свете модульности самого geom, это не потребует переписывания (или патчинга) имеющегося кода для работы fs
| | |
| |
| 8.12, Аноним (3), 19:47, 20/06/2006 [^] [^^] [^^^] [ответить] | +/– | именно, что жестоко что толку расширять функции geom а, если только fs знает гд... текст свёрнут, показать | | |
|
|
|
| 5.35, echo (??), 23:00, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 > в linux'е это сделано в виде независимого модуля jbd с самого начала, с 99 года.
я так понимаю, что подразумевается что разработчики фри не могли сделать это раньше,
потому что они "некомпетентные идиоты"?
эта фитча нахер никому не нужна была и будет юзаться только на домашних писссюках,
на которых скорость дисков не критична, упса нет а электричество отрубается
довольно часто. на оборудовании с защитой между скоростью дисков и подождать
несколько минут раз в десятилетие я выберу таки скоростные диски.
к 99 году у фри уже была устраивающая всех fs.
и сайчас эта разработка - напрасная трата времени.
очень скоро флэш-память заменит традиционные винчестеры и все ваши райзер-хуяйзер
станут историей, как флопповод на 5 дюймов. | | |
| |
| |
| 7.42, echo (??), 11:14, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>Мдаа. Ну вы, блин, и...
швейк рассказал как-то поучитильную историю как один гражданин имел привычку ходить
по пивным, чокаться с каждым встречным и приговаривать "вам на нас, нам на вас".
однажды он схлопотал по чайнику и в процессе выяснилось, что он имел в виду
"вам на нас, нам на вас нечего сердиться!"
поэтому, - поучал швейк, - нужно стараться выражать свои мысли яснее.
| | |
|
| 6.46, Аноним (3), 13:27, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
бла-бла-бла. никому эта фича на bsd не нужна, очевидно. потому как работает bsd только на домашних писюках. у всех остальных, кто хоть как-то связан с реальными приложениями масштаба предприятия (sgi/dec/m$/sun/etc) - давно есть журналирование. | | |
|
|
|
|
|
| 1.9, Аноним (-), 19:26, 20/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
видимо всетаки почитали сурсы солярки, бо там уже давно к уфс журналирование прикрутили ))))))) | | |
| |
| 2.14, Аноним (3), 21:00, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
ну раз вы прочитали, расскажите всем нам в каком там месте транзакции описываются. | | |
| |
| 3.15, universite (ok), 21:26, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 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.
| | |
| |
| 4.16, Аноним (3), 21:30, 20/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
ага. покажите где здесь "транзакция". или уважаемый автор предлагает "терминировать" журнал посередине какой-нить creat(2) или rename(2) ? | | |
| |
| 5.18, Квагга (?), 08:43, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
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.20, sauron (??), 09:13, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >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 не используются. | | |
| |
| 7.21, Квагга (?), 09:41, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Такой подход даст ЮФС журналирование.
Не думаю, чтобы падение производительности оказалось заметным. | | |
| |
| 8.23, Аноним (3), 09:58, 21/06/2006 [^] [^^] [^^^] [ответить] | +/– | ну да, ну да двойная запись _всего_ в разные участки диска конечно же не окажет... текст свёрнут, показать | | |
| 8.25, sauron (??), 10:23, 21/06/2006 [^] [^^] [^^^] [ответить] | +/– | Еще как даст Единственная FS которая под linux журнализирует данные а не метада... текст свёрнут, показать | | |
| |
| 9.26, Аноним (3), 10:33, 21/06/2006 [^] [^^] [^^^] [ответить] | +/– | не нужно лжи по-умолчанию ext3 работает в ordered mode это означает, что журна... текст свёрнут, показать | | |
|
|
|
| 6.22, Аноним (3), 09:55, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
LOL. ну и где здесь декларация начала-конца транзакции в ufs? как этот доморощеный gjournal узнает когда все текущие операции завершены? я уже не говорю о том, что нет возможности выбрать режим журналирования writeback/data/ordered, что на время терминирования журнала (читай сброса на диск) заблокированы любые модификации и так далее. децкая поделка. | | |
|
|
|
| 3.17, butcher (ok), 08:08, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Ключевые слова:
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. | | |
| |
| 4.24, Аноним (3), 10:01, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
таки придется что-то в ufs менять? ай-яй-яй ... как уже было сказано, журналирование данных - это вещь тормозная по определению. об чем сам автор и написал. так что давайте там, не изобретайте велосипед с квадратными колесами. | | |
|
|
| 2.19, sauron (??), 09:11, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Мдя... в результате получаем туже производительность что у ext3. Причем в не зависимости от файловой системы. Будь то XFS ReiserFS или любая другая. Ганс вон хочет чтобы его reiserfs с отдельными плагинами в ядро включили. А тут все раз-раз и в дамках одно слово офигеть. | | |
|
| 1.28, X0R (?), 11:10, 21/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
непонял. вообще то во фре есть алтернаимва журналированию - soft updates.
нафиг вообще нужно это журналирование | | |
| |
| 2.29, Аноним (3), 11:23, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
это не альтернатива, это костыль. SU не спасают от необходимости запуска fsck. fsck хорошо нагружает диск. система, соответственно, тормозит. когда у вас терабайтная fs, fsck будет работать очень долго и система тоже будет долго тормозить. воостановление через журнал - это максимум несколько секунд, независимо от размера fs. | | |
| |
| 3.33, SunTech (?), 17:12, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Не знаю на каких у вас там дисках очень долго всё запускается, а у меня на 4х400Gb RAID5 (файлсервер с папкой обмена и интенсивной записью более 50 клиентов одновременно) после внезапного выключения и повторного включения поднимается довольно быстро, пять минут не решают, если пользователи уже заметили отсутствие услуги.
А по мне так вообще нахрен этот журнал не нужен, на всех серверах стоит софт, который корректно заглушит и машину и бесперебойник в случае пропажи электричества.
Более того, на машинах с дисковыми контроллерами с кешами по 128 Мбайт и отсутствием аккумулятора для его подпитки, фатальность потери данных из кеша с наложением журналирования достаточно серьезная вещь, боюсь что после этого журнал уже будет бесполезен. | | |
| |
| 4.34, Аноним (3), 19:01, 21/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
ага, безумно огромная fs - 1,2TB. вашим пользователям может и пол-часа не решают.
только не у всех же такие безденежные пользователи ;)
ну да, видели мы на M9 супернадежную систему обеспечения питанием, которая накернулась
с пропажей питания. и да, конечно, у вас-то этого никогда не случится. куда там какой-то M9
до вас ...
про кэш на контроллере - это вы глупость сказали. нормальный контроллер понимает штуки
типа ordered tag и так далее. | | |
| |
| 5.51, XAD (?), 11:54, 24/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
про нормальный контроллер - это вы глупость сказали.
потому что нормальный контроллер сортирует сектора в порядке их расположения на диске перед записью | | |
|
|
| 3.44, X0R (?), 11:35, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
а разве fsck на фре работает не в фоне? или я ошибаюсь
вот на линуксе я ощущаю работу fsck при старте- это точно | | |
| |
| 4.45, echo (??), 12:02, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
>а разве fsck на фре работает не в фоне? или я ошибаюсь
>вот на линуксе я ощущаю работу fsck при старте- это точно
запуск на фоне - тоже никому не нужная фитча, которую сделали в 5.x
fsck на фоне грузит винт так, что остальные приложения не могут нормально
работать. в итоге всё равно приходиться ждать, и ждать гораздо дольше, т.к.
ось не в однопользовательском режиме. а если прикладная прога поюзает
кривые иноды раньше fsck?
я давно рамечаю винт одним девайсом и не парюсь.
один единственный раз fsck не справился с работой и я почекал фс с флоппика.
лучше я буду уверенным, что приложения работают на чистой fs.
я тоже не в восторге, когда приходиться юзать рыбий жир.
| | |
| |
| |
| 6.50, echo (??), 00:04, 23/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
> Пока не fsck - НЕ загрузится.
да не нужет он загруженный без fsck. всё равно тормозит и толком не работает.
пусть почекается и загружается нормально. раз в году авария такая бывает, 5 минут
в лом подождать?
раз по дефолту журналирование данных на ext3 не включено, значит его никто и не юзает.
больше разговоров. не нужная это фитча, просто, наверное, достали ламмеры своими
"а вот у вас fs не журналируемая". ну так нате, вот теперь журналируемая.
только никто это юзать не будет.
крутая технология, fs чекать каждые несколько секунд. прямо фонтан гениальных идей.
купи упса и не парься.
| | |
| |
| 7.52, Аноним (3), 14:39, 27/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
гыгыгы. по умолчанию ext3 журналирует _метаданные_, чего достаточно для обхода fsck.
а ваше "журналирование" всего в ufs - это да, нафиг такое поделие.
ups не решает проблему полностью. просто потому, что ядро может накернуться. вследствии
ошибок железа, драйверов или просто ядра. понятно, что у freebsd такого не бывает ;) | | |
| |
| 8.53, echo (??), 16:18, 27/06/2006 [^] [^^] [^^^] [ответить] | +/– | если почитаешь выше, то увидишь, что это уже обсуждалось если бы была реальная п... текст свёрнут, показать | | |
| |
| 9.54, Аноним (3), 19:28, 27/06/2006 [^] [^^] [^^^] [ответить] | +/– | не нужно отсылать меня к каким-то там обсуждениям -- я умею читать маны в качес... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.30, ErrSkin (?), 12:40, 21/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Собственно, зачем для UFS2 журналирование? Неужели чего-то в ней не хватает? Просто интересная разработка с ограниченным кругом применений. | | |
| 1.31, edwin (ok), 13:43, 21/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > зачем для UFS2 журналирование?
Просто к примеру в случае аварийного reboot'а сервера сильно ускорится проверка разделов.
А за это стоит поборотся. | | |
| 1.36, echo (??), 23:35, 21/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
вообще-то команда фрибзди не всегда верно выбирает путь развития. совершенно дебильно,
например, они разнесли базовую ось и пакаджи на разные диски. ни разу в жизни (юзаю юздю
с 99 года) не пользовался LiveCD. всегда сливал один диск, теперь надо сливать два.
не говоря уже о сценарии, который теперь просит несколько раз поменять эти диски в
процессе установки пакаджа.
я сам программист и хорошо понимаю, что интерес человека к какой-то области очень часто
перевешивает реальную полезность и нужность данной работы если работа не направляется
твёрдой рукой технически грамотного руководителя.
совершенно не согласен с тем, что нежурналируемая fs была "ахилесовой пятой".
эта работа - напрасная трата драгоценного времени высококвалифицированого специалиста.
| | |
| |
| 2.37, Аноним (3), 07:05, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
ну да, вся freebsd - напрасная трата времени. ясное дело, что нет ничего правильнее fsck на терабайтных fs. | | |
| 2.56, azimut (?), 16:23, 07/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>вообще-то команда фрибзди не всегда верно выбирает путь развития. совершенно дебильно,
>например, они разнесли базовую ось и пакаджи на разные диски. ни разу
>в жизни (юзаю юздю
>с 99 года) не пользовался LiveCD. всегда сливал один диск, теперь надо
>сливать два.
>не говоря уже о сценарии, который теперь просит несколько раз поменять эти
>диски в
>процессе установки пакаджа.
Это связано с тем что 99% пользователей фряхи не пользуются пакэйджами, а вам было лень элементарно открыть хэндбук и прочитать про систему портов. Пакэйджи в дистрибутивах BSD содержат безумно устаревший софт, и чем дальше, тем более устаревающий. Т.е. не команда фрибзди дибильно что-то делает, а вам надо меньше авторитетно высказывать мнение и больше изучать возможности команды man.
| | |
|
| 1.39, Dorlas (??), 07:49, 22/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
1) Вообще то это глупость - ставить при инсталляции кучу package. (Вы же соврем не видите комментарии, которые появляются после установки большинства пакетов! - они полезны!) Правильный Вариант (и во FreeBSD и в Linux) иметь каталог (DVD-диск), где все нужные пакеты (rpm-ки, дистфайлы) находятся в одном месте. Если в Debian 11 CD, и мы ставим очень много сразу, диски тоже менять будем...
2) Если Вы сливаете из Интернета диски (есть возможность), то кто Вам мешает пользоваться портами? Слили мини-инсталляцию, поставили минимум + порты и вперед! И по трафику выйдет меньше в разы (чем скачивать 2 CD).
3) Логика программистов меня всегда поражала :) | | |
| |
| 2.40, echo aka andr.ru (?), 10:21, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
> 1) Вообще то это глупость - ставить при инсталляции кучу package. (Вы
не учи отца ибаца. геммарой происходил при установке кде для 5.3 (сейчас может исправили)
я как раз из тех, кто долго и вдумчиво выбирает, чего не надо ставить.
в итоге кде требуется куча всягой требухи и от просит диск номер один
несколько раз.
в итоге я стал ставить кде из портов. длго, ну и хснм, это не каждый день делается
> 2) Если Вы сливаете из Интернета диски (есть возможность), то кто Вам
> мешает пользоваться портами? Слили мини-инсталляцию, поставили минимум + порты и вперед!
скорость, мля! кде на целероне 1,7 собирался 3 дня.
я утром прихожу, а там дебильный вопрос с дебильным меню дебильного цвета а-ля нортон
коммандир. какой идиот это придумал? хоть бы переменную определили USE_DEFAULT=yes
> 3) Логика программистов меня всегда поражала :)
а, так ты ещё и не программист. тогда понятно, ты гораздо умнее остальных.
| | |
| |
| 3.47, LOL (??), 15:11, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
>скорость, мля! кде на целероне 1,7 собирался 3 дня.
>я утром прихожу, а там дебильный вопрос с дебильным меню дебильного цвета
>а-ля нортон
>коммандир. какой идиот это придумал? хоть бы переменную определили USE_DEFAULT=yes
Там "нормальный вопрос, нормального цвета". Мне, например, нравится. И DEFAULT=yes тоже там есть - нада уметь пользоватся, а не обзывать всех подряд непристойными выражениями. Стыдно, товарисч. | | |
| |
| 4.48, echo (??), 15:41, 22/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
> Там "нормальный вопрос, нормального цвета". Мне, например, нравится. И DEFAULT=yes тоже
ну да, должен быть, это я сейчас соображаю, а тогда не посмотрел
> есть - нада уметь пользоватся, а не обзывать всех подряд непристойными
> выражениями. Стыдно, товарисч.
а кого конкретно я обзываю? я так, про всех, никого лично.
а цвета нортон коммандира мне не нравятся как класс.
чёрно-зелёная консоль рулез форева.
| | |
|
| 3.57, azimut (?), 16:27, 07/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>скорость, мля! кде на целероне 1,7 собирался 3 дня.
Открой для себя ключи команды make. man make
>я утром прихожу, а там дебильный вопрос с дебильным меню дебильного цвета
>а-ля нортон
>коммандир. какой идиот это придумал? хоть бы переменную определили USE_DEFAULT=yes
Есть там эта переменная, определяется в /etc/make.conf. Хоть для всех портов, хоть для конкретного специально.
>> 3) Логика программистов меня всегда поражала :)
>а, так ты ещё и не программист. тогда понятно, ты гораздо умнее
>остальных.
Ну ты-то точно не программист. Программисты умеют читать документацию, а не только писать.
| | |
|
|
|
