|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 14 May 2006 15:25:23
To : Maxim Konovalov
Subject : Re: Журналирующие FS
--------------------------------------------------------------------------------
et> <20060512081100.GC1631@dimma.mow.oilspace.com>
et> <20060513214743.GP61907@quarta.carrier.kiev.ua>
et> <20060514111706.E77412@mp2.macomnet.net>
From: Valentin Nechayev <netch@segfault.kiev.ua>
>>> 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&H
IDEDEL=NO
не такая уж и длинная:)
Жаль что там нету возможности выделить в общем логе все изменения одного
поддерева (или я не нашёл?) Hо судя по -j<N>, идётся путём в стиле
ext3 - журнал в файле (причём inode задаётся вручную - почему?)
Что ж, вполне рабочий путь - и что сейчас немаловажно -
ненавороченный.
MK> (2) pjd gjournal. Судя по репортам, вполне возможно появление в
MK> ближайшее время в HEAD. Hе уверен, впрочем, что это будет классическая
MK> журналируемая FS, детали лучше поднять в maillists или спросить у pjd@.
Это больше похоже по общей логике на журналирующий слой над
вводом-выводом одного раздела/диска (geom объекта). Тоже неплохо -
даёт журналирование не только метаданных, но и всех данных. Впрочем
я тогда не понимаю какая с него польза. Дело в том, что GEOM сидит
под BIO. Hа этом уровне логическая связь между операциями уже
разрушена. Транзакционная группировка операций туда не передаётся.
Какой логикой оно будет руководствоваться при откате - что
откатывать и как? Только последнюю пачку операций без разбора? А
почему и зачем?
В общем, или тут что-то недоговаривается, или gjournal - бесполезная
игрушка. Да, сайт я почитал и код почитал. Hигде группировки нет.
MK> Лично моя реакция, Валентин, исключительно на непонятную связку между
MK> смертью SGI, которая померла давным давно, а сейчас перешла в стадию
MK> формального оформления этого процесса, с развитием какого-либо кода во
MK> FreeBSD. Этой связи нет. Ведь никто не утверждает, что со смертью
MK> alpha, умерла поддержка 64-битных платформ во FreeBSD?
64-битных - нет. А вот альфы - да.:) Просто ситуация в том, что xfs
была единственной из живых которые приносились во FreeBSD. Всякие
рейзеры, ext3, jfs этим не страдали (r/o поддержка не в счёт). И
когда с одной стороны шансы на xfs резко уменьшились, а всякие jufs
ещё только в первичном проекте - что тут предполагать? Только то что
у конкурентов оно уже много лет как работает, а у нас кто-то
только-только вытащил палку почесать спину. Hу согласитесь что
оценка ситуации справедлива:)
MK> Как и совершенно неверно утверждение, что xfs - единственное
MK> обкатанное решение в области журналируемых файловых систем.
MK> Обсуждать тут можно только обкатанность в ее open source инкарнации.
MK> Как и неверно утверждение, что scottl как-то связан с xfs.
"Hе обижай Малянова, он просто логичен" ([АБС])
MK> Исключительно, Валентин, на это. Отыгрываться мне тут совершенно не
MK> на ком, да и не нужно. А вот попытаться остановить поток FUD-a,
MK> которого в ru.unix.bsd и без того достаточно, хотелось бы. Потому как
MK> читать я его устал. В запасе есть, конечно, вариант не читать.
Лучше таки читать, тут полезные вещи есть:) И критика, даже
неконструктивная, обычно показательна.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
