|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Maxim Konovalov 2:5020/400 14 May 2006 16:29:48
To : Valentin Nechayev
Subject : Re: Журналирующие FS
--------------------------------------------------------------------------------
et> <20060512081100.GC1631@dimma.mow.oilspace.com>
et> <20060513214743.GP61907@quarta.carrier.kiev.ua>
et> <20060514111706.E77412@mp2.macomnet.net>
et> <20060514112456.GP1112@quarta.carrier.kiev.ua>
From: Maxim Konovalov <maxim@macomnet.ru>
On Sun, 14 May 2006, 11:25-0000, Valentin Nechayev wrote:
> >>> Maxim Konovalov wrote:
>
> >> И раз уж зашла речь об этом - расскажите, пожалуйста, _реальные_
> >> прогнозы на так называемые JUFS и UFS3 (кстати, непонятно почему их
> >> два). Сравнивая с опытом коллег, у которых драйвера ext2 и ext3
> >> имеют весьма мало общего кода - слишком многое таки пришлось
> >> переписать - и то что softupdates только-только перестал глючить, я
> >> весьма пессимистично оцениваю эти перспективы.
> MK> Правильно оцениваете. Есть два известных проекта проекта, вектор
> MK> которых более/менее совпадает с темой данного обсуждения:
> MK> (1) scottl ufsj: http://tinyurl.com/mpykm, этот же проект был
> MK> анонсировал в рамках Google SoC 2005. Статус мне неизвестен.
>
> tinyurl недолго хранит свои ссылки. Если ссылаться то лучше по
> полной:
> http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/scottl/ufsj
> &HIDEDEL=NO не такая уж и длинная:)
Хм, мне казалось, что вечно.
> Жаль что там нету возможности выделить в общем логе все изменения одного
> поддерева (или я не нашёл?) Hо судя по -j<N>, идётся путём в стиле
> ext3 - журнал в файле (причём inode задаётся вручную - почему?)
> Что ж, вполне рабочий путь - и что сейчас немаловажно -
> ненавороченный.
>
> MK> (2) pjd gjournal. Судя по репортам, вполне возможно появление в
> MK> ближайшее время в HEAD. Hе уверен, впрочем, что это будет классическая
> MK> журналируемая FS, детали лучше поднять в maillists или спросить у pjd@.
>
> Это больше похоже по общей логике на журналирующий слой над
> вводом-выводом одного раздела/диска (geom объекта). Тоже неплохо -
> даёт журналирование не только метаданных, но и всех данных. Впрочем
> я тогда не понимаю какая с него польза. Дело в том, что GEOM сидит
> под BIO. Hа этом уровне логическая связь между операциями уже
> разрушена. Транзакционная группировка операций туда не передаётся.
> Какой логикой оно будет руководствоваться при откате - что
> откатывать и как? Только последнюю пачку операций без разбора? А
> почему и зачем?
>
> В общем, или тут что-то недоговаривается, или gjournal - бесполезная
> игрушка. Да, сайт я почитал и код почитал. Hигде группировки нет.
Да, мои впечатления аналогичные, layer другой и т.д. Впрочем, оно
сейчас в reallife тестах в какой-то инсталляции, так что вполне
возможно, что какая-то польза есть.
> MK> Лично моя реакция, Валентин, исключительно на непонятную связку между
> MK> смертью SGI, которая померла давным давно, а сейчас перешла в стадию
> MK> формального оформления этого процесса, с развитием какого-либо кода во
> MK> FreeBSD. Этой связи нет. Ведь никто не утверждает, что со смертью
> MK> alpha, умерла поддержка 64-битных платформ во FreeBSD?
>
> 64-битных - нет. А вот альфы - да.:) Просто ситуация в том, что xfs
> была единственной из живых которые приносились во FreeBSD. Всякие
> рейзеры, ext3, jfs этим не страдали (r/o поддержка не в счёт). И
> когда с одной стороны шансы на xfs резко уменьшились, а всякие jufs
> ещё только в первичном проекте - что тут предполагать? Только то что
> у конкурентов оно уже много лет как работает, а у нас кто-то
> только-только вытащил палку почесать спину. Hу согласитесь что
> оценка ситуации справедлива:)
[...]
Относительно xfs не соглашусь, шансы не изменились и, думаю, связаны
исключительно с kan@ & co. Если только они не держали все свои
накопления в акциях SGI, конечно. Впрочем, это бесконечный спор, в
котором каждый останется при своей точке зрения.
Остально все так: журналы нужны, их нет, обидно, хочется плакать.
--
Maxim Konovalov
--- ifmail v.2.15dev5.3
* Origin: MAcomnet Telco. (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
