UFS2+journal

Ну и что тут подробного? То же самое что в доках и в mail-list'е по этому делу. Хотя бы написали какие грабли могут быть, чем черевато. ИМХО полезно только для тех кто по английски ни бум-бум, и то спорный вопрос, а то какой нибудь такой горе админ решит прикрутить к серверу и всё, появится ещё один красноглазый который будет кричать BSD suxx, у меня всё упало.

почему то мне кажется что UFS уже ничего не поможет

> а то какой нибудь такой горе админ решит прикрутить к серверу

экспериментальные фичи на сервере? убивать таких админов надо

Тут даже не столько UFS, сколько возможность GEOM делать журналирование (почти нормальное журналирование) для любой fs. UFS от этого на мой взгляд ни холодно ни жарко. Кто нибудь знает как в линухе это реализовано? Кодом под каждую конкретную фс, или ещё как?

журналирование абстрактной файловой системы -- чушь, т.к. только она знает, что у нее является транзакцией, а что нет.

Кто нибудь читал этот "перл" ???

Чего стоит фраза: "возможно имеет смысл пересобрать весь мир"

Когда в оригинальном руководстве сказано именно пересобрать мир.

Короче - в топку.

Вот нормальный перевод: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=67275+0+current/freebsd-current

>журналирование абстрактной файловой системы -- чушь, т.к. только она знает, >что у нее является транзакцией, а что нет.

во-первых не абстрактной, а UFS,
во-вторых как ты думаешь для чего предназначены callbacks geom?

Не тот линк дал ... вот нормальный http://wiki.bsdportal.ru/doc:gr_gjournal

Ох ты блин, а бсдшники не знают, вот засада. Вообще если отталкиваться от этого изречения, то и вся их GEOM система тоже туфта и не должна работать (man geom).

По поводу новости уж лучше оригинал почитать http://groups.google.ru/group/fa.freebsd.current/msg/1efcf3177bb109c9

Да кстати, новость про журналирвание сильно "обсосали" на opennet.ru, и вот как раз цитата из оригинального письма: 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.

Т.е. журналируем иммено абстрактную фс. Вроде так.

>but it *has hooks* which allow to work with file systems.

не совсем абстрактную

>Т.е. журналируем иммено абстрактную фс. Вроде так.

кстати, аналог в линукс - "jbd", его использует ext3 и еще какая-то фс,
и конечно он появился давным давно.

А не боян? http://www.linux.org.ru/jump-message.jsp?msgid=1455265

> Кто нибудь знает как в линухе это реализовано? Кодом под каждую конкретную фс, или ещё как?

Насколько мн еизвестно - каждая ФС обеспечивает журналирвоание сама. Ядро предоставляет только стандартное API, реализация которого ложится на плечи ФС.

>почему то мне кажется что UFS уже ничего не поможет и чем ты это аргументируешь?

> и чем ты это аргументируешь?

сравни ее хотя бы с reiserfs, не говоря уже о reiser4

в силу своей архитектуры ufs клинический тормоз

Автор - SOKO1????

Ну что вы хотите от студентика?? :) А вы знаете, он даже форкнул Фрю!

Кому нужен журнал? По-моему, только красноглазым БСДшникам!!

>Насколько мн еизвестно - каждая ФС обеспечивает журналирвоание сама.

ls /usr/src/linux/fs/jbd

но естественно фс может не использовать jbd.

>Когда в оригинальном руководстве сказано именно пересобрать мир.

Автор прав! Зачем пересобирать весь мир, когда изменение касаются только созданных директорий? Это всеравно что после обновления при csup'е утилиты /bin/cp пересобирать весь мир, когда изменения затронули только cp.

и не просто может, но таки не использует, как правило 8)

> в силу своей архитектуры ufs клинический тормоз

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

---vk

"мужики-то не знают" - ага, мужики точно не знают ;)
для высокопроизводительных файл серверов в сан пользуют ТОЧНО не UFS :)
а веритас например или сейчас уже zfs...

и тормозит UFS на солярке тоже нехило...

А почему я должен что то сравнивать если ты говоришь нам что "UFS уже ничего не поможет", это ты должен сравнить и доказать.
И да, что именно такое плохое в архитектуре UFS?

> мужики-то не знают. и в sun почему-то используют именно ее -- для высокопроизводительных файл-серверов, например.

ну справедливости ради стоит заметить что в solaris всё таки сильно отличающийся от бсдишного UFS с кучей различных фич, в т.ч. нормальный logging, а для высокопроизводительных файл-серверов есть более кошерная zfs ;)

---kuvkir

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

xfs vs ufs+su. Железо абсолютно одинаковое:

http://segfault.newmail.ru/freebsd.html http://segfault.newmail.ru/linux.html

Ещё вопросы?

В общем всё, "UFS уже ничего не поможет", всем БЗДшникам стреляться и вешаться, они оказывается нормально работать не могут, потому что у них всё тормозззззииииит.

ЗЫ Блин, что ж выбрать то? И вешаться не хочется и стреляться тоже не особо.

И насколько я понимаю, журналирование ещё больше тормознуло UFS.

>Тут даже не столько UFS, сколько возможность GEOM делать журналирование (почти нормальное журналирование) для любой fs. UFS от этого на мой взгляд ни холодно ни жарко. Кто нибудь знает как в линухе это реализовано? Кодом под каждую конкретную фс, или ещё как?

Журнал реализуется через стандартный JBD (хотя насколько я помню, reiser делает сам). GEOM journal это практически один в один JBD.

>gloomdemon (*) (28.06.2006 11:50:10)

>Да кстати, новость про журналирвание сильно "обсосали" на opennet.ru, и вот как раз цитата из оригинального письма: 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.

>Т.е. журналируем иммено абстрактную фс. Вроде так.

Как раз как JBD в Linux (ext3, ocfs).

>gloomdemon (*) (28.06.2006 12:20:45)

>и не просто может, но таки не использует, как правило 8)

ага, только никому не нужные фс, типа ext3 ее используют.

>Журнал реализуется через стандартный JBD (хотя насколько я помню, reiser делает сам). GEOM journal это практически один в один JBD.

В ext3 и ocfs2.

> xfs vs ufs+su. Железо абсолютно одинаковое: 
> http://segfault.newmail.ru/freebsd.html http://segfault.newmail.ru/linux.html
> Ещё вопросы?
1. uname -rsmp?
2. Версия UFS (1/2)?
3. UFS_DIRHASH вкомпилен? Да и вообще конфиг ядра + что крутил в sysctl?

>xfs vs ufs+su. Железо абсолютно одинаковое:

http://segfault.newmail.ru/freebsd.html http://segfault.newmail.ru/linux.html

Ещё вопросы?

Какая версия FreeBSD?

> сравни ее хотя бы с reiserfs, не говоря уже о reiser4

reiser идет лесом, ее никогда в ядро не включат, так и будет в виде патчей.

а вы видели этот UFS_DIRHASH изнутри? буагагагагагага. вот все в bsd так сделано, через ...

хм. в соседнем треде пролетала ссылка на http://www.unixtech.ru/analytics/UFS_VxFS_QFS_ZFS_BenchmarkResults.pdf, где показывалось, что под очень сильной нагрузкой и zfs, и veritas заметно уступают солярному ufs. жду комментариев по тому, что и как авторы бенчмарка неправильно меряли.

---vk

>1. uname -rsmp? 6.1-RELEASE, i386, камень cel 2.8GHz Винты - wd 360GD (raptor)

>2. Версия UFS (1/2)? v2

>3. UFS_DIRHASH вкомпилен?

конечно.

Да и вообще конфиг ядра + что крутил в sysctl? флуд получится. Обе системы тестировались с персобранными с march=i686 -O2

sysctl нигде не трогал.

>а для высокопроизводительных файл-серверов есть более кошерная zfs ;)

Эдак грустно, кругом евреи, и всюду они ищють кошерненького..... :(

> а вы видели этот UFS_DIRHASH изнутри?

Можете предложить лучшую идею/реализацию?
[-- CUT --]
/*
 * Dirhash uses a score mechanism to achieve a hybrid between a
 * least-recently-used and a least-often-used algorithm for entry
 * recycling. The score is incremented when a directory is used, and
 * decremented when the directory is a candidate for recycling. When
 * the score reaches zero, the hash is recycled. Hashes are linked
 * together on a TAILQ list, and hashes with higher scores filter
 * towards the tail (most recently used) end of the list.
 *
 * New hash entries are given an inital score of DH_SCOREINIT and are
 * placed at the most-recently-used end of the list. This helps a lot
 * in the worst-case case scenario where every directory access is
 * to a directory that is not hashed (i.e. the working set of hash
 * candidates is much larger than the configured memry limit). In this
 * case it limits the number of hash builds to 1/DH_SCOREINIT of the
 * number of accesses.
 */
[-- CUT --]

А для всех, кто не понимает выгод GEOM можно посоветовать прочитать man по паре ссылок:

http://www.freebsd.org/cgi/man.cgi?query=graid3
http://www.freebsd.org/cgi/man.cgi?query=ggated
http://www.freebsd.org/cgi/man.cgi?query=ggatec

После прочтения - подумать над применением.

> а мужики-то не знают. и в sun почему-то используют именно ее -- для высокопроизводительных файл-серверов, например.

вообще на "высокопроизводительных файл-серверах" используется zfs

> И да, что именно такое плохое в архитектуре UFS?

хотя бы то, что разрабатывали ее под маленькие и тормозные винты, а это было (могу ошибаться) едва ли не 30 лет назад

Я исходники читал только для XFS и (поверхностно) reiser. ни та ни другая не пользует.

btw, кто смотрел плотно ocfs2? я пока даже не начинаю, пока ядро с ним даже в debian testing нет...

> вообще на "высокопроизводительных файл-серверах" используется zfs

гыгыгы. ей сколько лет отроду? 10? 20? "используется" ... для приличия сказали бы "пробуют использовать".

> Можете предложить лучшую идею/реализацию?

конечно могу. выкинуть этот костыль и сделать b+tree или htree. опять bsd изобрели велосипед с квадратными колесами.

> А для всех, кто не понимает выгод GEOM можно посоветовать прочитать man по паре ссылок:

а для всех, кто ничего другого не читал, доводим до сведения, что в линухе все это работает без geom. сюрприз?

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

кто мне объяснит на кой хрен журнал ufs если fsck работать с журналом не умеет? исходники патча смотрел, там fsck не патчится.

> кто мне объяснит на кой хрен журнал ufs если fsck работать с журналом не умеет? исходники патча смотрел, там fsck не патчится.

очевидно сам gjournal занимается replay'ем.

> очевидно сам gjournal занимается replay'ем.

А где гарантия что fsck не грохнет журнал? А то сначала fsck сделает "реплей" а потом geom. Я на это посмотрю :). В общем еще работать и работать.

>btw, кто смотрел плотно ocfs2? я пока даже не начинаю, пока ядро с ним даже в debian testing нет...

Oracle даже на странице этой ФС не выложил никаких тестов производительности, но зато заявлены интересные кластерные возможности распределенного хранения данных.

>Zulu **** (*) (28.06.2006 22:16:47)

красноглазием болеют только тупые гентушники.