Installing DragonFlyBSD

Пусть и БСД-сообщество мучается от клонов!

> Пусть и БСД-сообщество мучается от клонов!

Ничего, их у нас не много :_)). И все добрые, милые и надежные. Не то что ваши. :-)

Остров

в-в-вы ещ-щ-ще под-д-дерит-т-тесь гор-р-ряч-ч-чие эстон-н-нски-и-е пар-р-рни

It covers the commits logged into the HEAD (-CURRENT) branch of the FreeBSD CVS Repository. These reports are generated every monday night.
.
.
.
First DragonflyBSD merge
Jeffrey Hsu (hsu) merged some TCP code from DragonflyBSD_. Alexey Dokuchaev suspects that this is the first merge from Dragonfly that FreeBSD has seen.

"Alexey Dokuchaev suspects that this is the first merge from Dragonfly that FreeBSD has seen"
И совершенно напрасно... Andre переносил что-то до этого.

Кстати, продвинутые dfbsd-еры тащат из FreeBSD 5.x что ни попадя, и регулярно забывают помянуть авторов а credits. Так и рождаются великий гуру ACPI, ATA и PCI asmodai с компанией...

> Хотят сделать продвинутый SMP

Как? Все еще хотят???

>> Хотят сделать продвинутый SMP

>Как? Все еще хотят???

Нет, более продвинутый.

Иногда происходит и обратный процес - FreeBSD берёт что-то из DragonFlyBSD. Вот например:

http://lists.freebsd.org/pipermail/cvs-src/2004-January/017121.html

> Хотят сделать продвинутый SMP

Рожденный ползать, летать не может :-))

> Рожденный ползать, летать не может :-))

Не пойму о чем ты? Matt Dillon как раз позиционирует свой проект как более шуструю альтернативу FreeBSD 5.x. Только вот вопрос, получится ли?

"Из мухи можно сделать слона, но летать она уже не сможет" ;) Использую Linux/FreeBSD, но никакого смысла - что же мне даст эта Стрекоза - не вижу. Ну хочет человек улучшить FreeBSD - что ж, почему он не попытается своими улучшенными идеями повлиять на Фряшных коммитеров? Есть у меня многопроцессорные сервера - хоть многие ругают тут FreeBSD-шную SMP-реализацию, я что-то ею не расстроен - все работает не менее стабильней Линуха. У Фри есть одно больное место, которое ни с чем несравнимо - это стабильность ее файловой системы. Вот что надо улучшать. Помнится, была 2 года назад в новостях бета журнальной файлосистемы. Ну де же она? Кто-нибудь пробовал - изменить файл, сохранить и в течении 5 минут нажать PowerOff/Reset на UnionFS? Файл останется на месте. Но пустой. И это в 5.2RC... !!!!!!! Миссия таких форков дистрибутивов для меня - очень смутна. УЛУЧШИТЬ, УСКОРИТЬ.. Если они все такие самые лучшие - то почему в мире Unix так много форков ;-) Я не говорю о таких ветках диструбтов RedHat, SlackWare, Debian - у этих довольно четко вырисовываются различия. А вот сколько в России сейчас еще плодят всяких TurboLinux-ов и тд? Чего бы они не писали у них у всех одна миссия - урвать бабки на чужем коде. Вам ведь интересно - что это за _НОВЫЙ_ дистриб лежит на полке? =) Хочу просто здесь спросить о взглядах у тех, кто посмотрел на отличия DragonFly. Что вы о нем думаете - серъезный ли проект.

> больное место, которое ни с чем несравнимо - это стабильность ее файловой системы

А когда вышла бета ext3 тут все любители бсди кричали, какой рулез
soft updates, и что soft updates лучше любого журнала...

> А когда вышла бета ext3 тут все любители бсди кричали,

я любитель бсди, и я кричу что вышеописанная ситуация на включенных SoftUpdates - дрянь.Незнаю кто о чем кричит, но плюсы и минусы есть у всех.

> А когда вышла бета ext3
А оно что, перестало быть дерьмецом от этого?

> Иногда происходит и обратный процес - FreeBSD берёт что-то из DragonFlyBSD. Вот например:
> http://lists.freebsd.org/pipermail/cvs-src/2004-January/017121.html

Obtained from: DragonFlyBSD rev 1.6 (hsu)
^^^^^^^^^^^^^^ Это видим. Теперь учим деятелей от dfbsd поступать также, без необходимости в особом напоминании.

> Кто-нибудь пробовал - изменить файл, сохранить и в течении 5 минут
> нажать PowerOff/Reset на UnionFS? Файл останется на месте. Но пустой.
Кто-нибудь пробовал то же, но на jsf/xfs/reiser/ext3-not-full0-logging-mode? Когда журналируются мета-данные, как собираетесь добиваться отличного результата? Детство какое-то.

на reiserfs и ext3 (ordered) все ok

на reiserfs регулярно вылетают системы, благодарю покорно. я конечно понимаю, щас меня забросают "а у меня всё всё работает", но как бы наплевать на положительный опыт при наличии энного, далеко ненулевого, опыта отрицательного, как своего, так и чужого. Так что с reiser - в сад, слушать сатирические куплеты...

> ext3 (ordered) все ok
если это тот самый режим, который журналирует данные, то да. Ну так ведь в таком случае отдыхает скорость работы, или будем спорить?

вдогонку - а мы ударим по ordered сихронным монтированием, тоже всё ok будет. вопрос, какой ценой...

да ладно , data=ordered и data=journal совсем разные вещи,
и ordered будет понадежнее data=writeback или там xfs, jfs.
xfs, jfs ровненько удаляют содержимое файла при нажфтии reset.
И нормальная у ext3 performance - это с моего laptopa :

из bonnie++ :
ext3 ordered 13355 15099 7745 15559 20376
ext3 writeback 12861 14461 6978 15676 20569
reiserfs 11810 18431 7331 12014 16873
xfs 13838 21326 7783 19280 20855
jfs 13925 20679 8183 15592 20812

uman

> data=ordered и data=journal
ordered != journal, соответственно ситуация, описанная в начавшем эту бодягу в письме принципиально ВОЗМОЖНА. Утверждать обратное - демонстрировать незнание того, как ext3 собственно говоря работает в различных режимах.
Полную гарантию, помимо страхового полиса, в данном случае даст только data=journal. Но с соответствующими издержками. Извиняюсь за некоторую терминологическую путаницу вначале, я извёл все линуксы в округе под корень более года назад. В пользу FreeBSD, ест-но :)

> ordered != journal, соответственно ситуация, описанная в начавшем эту бодягу в письме принципиально ВОЗМОЖНА.

Не возможна.

> Утверждать обратное - демонстрировать незнание того, как ext3

Вот и продемонстрируй нам свои знания, а мы с тебя постебемся.

наш великий искроренитель linux объясните нам тогда что же такое
data=ordered ?

Искоренитель FreeBSD.

>на reiserfs регулярно вылетают системы, благодарю покорно. я конечно понимаю, щас меня забросают "а у меня всё всё работает", но как бы наплевать на положительный опыт при наличии энного, далеко ненулевого, опыта отрицательного, как своего, так и чужого. Так что с reiser - в сад, слушать сатирические куплеты...

Бля, как страшно жить...

из man mount:

"mount -o journal=update"
Mounts a filesystem with a Version 1 journal, upgrading the
journal dynamically to Version 2.

"mount -o data=journal"
Journals all data and metadata, so data is written twice. This
is the mode which all prior versions of ext3 used.

"mount -o data=ordered"
Only journals metadata changes, but data updates are flushed to
disk before any transactions commit. Data writes are not atomic
but this mode still guarantees that after a crash, files will
never contain stale data blocks from old files.

"mount -o data=writeback"
Only journals metadata changes, and data updates are entirely
left to the normal "sync" process. After a crash, files will
may contain stale data blocks from old files: this mode is
exactly equivalent to running ext2 with a very fast fsck on reboot.

И Видим:
> Data writes are not atomic
> but this mode still guarantees that after a crash, files will
> never contain stale data blocks from old files.

uman

>я любитель бсди, и я кричу что вышеописанная ситуация на включенных SoftUpdates - дрянь.Незнаю кто о чем кричит, но плюсы и минусы есть у всех.

Попробуй монтировать с опцией "-o sync" и уменьши значения переменных sysctl
kern.metadelay=5
kern.dirdelay=6
kern.filedelay=7
с 28,29,30 секунд соответственно по умолчанию, чтобы ускорить сброс буферов. Вероятность потерь данных должна значительно уменьшиться.

-> amy

вот те чисто человеческое спасибо =) А то я SoftUpdates отключил вообще - после того как, открыв большой файл и дописав пару строчек, пропало питание и я потерял куда больше чем было до редактирования.

И Видим:
> Data writes are not atomic
> but this mode still guarantees that after a crash, files will
> never contain stale data blocks from old files.

B не понимаем, что видим. "Never contain stale data blocks from old files." cовсем не значит, что file не останется _совсем_ без блоков. Что и требовалось доказать. Читайте исходники, ибо они свет...

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

>> ordered != journal, соответственно ситуация, описанная в начавшем эту бодягу в письме принципиально ВОЗМОЖНА.

> Не возможна.

Ох уж эти сказочники, ох уж эти сказки. Возможна.

1. Первая транзакция создаёт файл. create(2)
2. Вторая транзакция выделяет блок и помечает его как принадлежащий файлу. Соответсвующие inode и free bitmap блоки сидят в кеше.
3. data=ordered флушит соответсвующий data block на диск перед транзакцией #2 и сиcтема обламывается по той или иной причине до того, как транзакция #2 попадает в журнал на диске. При перезагрузке имеем файл с нулевой длиной, а наши данные сидят в блоке, который система считает свободным.

Вы можете продолжать веровать. Вам - можно.

> При перезагрузке имеем файл с нулевой длиной, а наши данные сидят в блоке, который система считает свободным.

А скажи, дарагой, для чего вообще ведется журнал транзакций? Если все
идет по твоему сценарию, он не нужен ;) И еще скажи, неужели твои
маленькие куриные мозги не осилили того факта, что при перезагрузке
происходят некоторые проверки журнала?

вот тормоз,
мы говорим о случае когда мы делаем append к файлу с данными,
если нажать reset с data=ordered мы можем потерять maximum поcледние
изменения , а для xfs,jfs ,data=writeback файл может быть пустым после
reboot.

> А скажи, дарагой, для чего вообще ведется журнал транзакций? Нужен. Без журнала ты б получил запись в иноде без соответствующей записи в block bitmap, что потенциально привело б к возможности использования одного и того же блока двумя файлами. Или наоборот, запись в free bitmap без единой ссылки на блок из инодов. И так далее, и тому подобное, несть числа возможностям. С журналом _непротиворечивость_ on-disk данных сохраняется.

> происходят некоторые проверки журнала? Вот и расскажи, знающий, _какие_ проверки спасут от вышеописанной ситуации. Марш читать исходники, фантазёр.

> а для xfs,jfs ,data=writeback файл может быть пустым после
> reboot.
Мда, сам-то понял произнесённый с пафосом идиотизм? Потерять ты сможешь максимум добавленные блоки, что в jfs, что в xfs, что в ext3. ext3=ordered спасёт отца русской демократии от прочнения грязных данных, оставленных предыдущим файлом-пользователем нововыделенного блока, или от блоков, забитых нулями, как это было замечено за XFS. И это _всё_.

Короче, двум предыдущим оппонентам - в церквь, молиться. С материальным миром им не по пути, они ВЕРУЮТ.

Переформатирую.

> А скажи, дарагой, для чего вообще ведется журнал транзакций? Если все
> идет по твоему сценарию, он не нужен ;)
Нужен, даже если ты этого осознать не в силах. Журнал нужен, чтобы предотвратить ситуацию, когда для некоторой операции нужно атомарно изменить несколько блоков, и сбой происходит до завершения всей последовательности. Простейший пример - выделение блока в файл. Для этого нужно а) пометить блок как занятый в block bitmap; b) прописать соответсвующую запись в inode (или в один из indirect блоков); c) изменить summary в caмом inode. Разрыв в этой последовательности может привести к дважды выделенному блоку, потерянному блоку, etc, в зависимости от того, в каком порядке syncer начнёт сбрасывать буфера.

> И еще скажи, неужели твои маленькие куриные мозги не осилили того
> факта, что при перезагрузке происходят некоторые проверки журнала?
Вот и расскажи, знающий, _какие_ проверки спасут от вышеописанной ситуации с двумя независимыми транзакциями.
В отличие от некоторых недотёп, я таки знаю, как работают ext3 и xfs, и свой пример привёл не зря. Хотя вру, наверное всё-таки зря, за полной беспросветностью оппозиции.

hint: journal replay

> hint: journal replay
_Что_ проигрывать вперёд собираемся? Блок данных при data-ordered в журнале не содержится, завершилась его запись, или нет, система не знает, commit record в журнале отсутствует.

Ответный хинт: чтение исходников рулит.