ext4 - файловая система нового поколения.

Это очень подробно и часто обсуждалось и здесь и в других местах. Например http://www.opennet.ru/openforum/vsluhforumID3/16151.html

<cite>
Напротив, Торвальдс по поводу reiser4 давно не высказывался. И к стилю программирования претензии давно не выдвигаются -- в ход пошли гораздо более серьезные аргументы. Главные идеолги "невключения" reiser4 -- Мортон и Кокс.

В общих чертах суть их недовольства заключается в том, что reiser4 не только мало использует generic-код, предназначенный для автоматизации рутинной работы, наличиствующей почти во всех ФС (типа generic-read, generic-write, тесно интегрированные со страничным и блочным кэшами), но и своими плагинами вносит в ядро избыточную функциональность, уже реализованную в слое VFS. Где-то они, конечно, правы. Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут в основном благодаря отказу от их использования.

По-русски говоря -- они уперлись лбами и уже больше года дале не движется.
</cite>

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

> А что мешает заменить плохие негодные существующие функции в ядре быстрыми и шустрыми функциями от райзера?

то, что у рейзера они отнюдь не лучше, как тут наивно утверждалось.

> А что мешает заменить

кокс мешает, или Кокс, но тогда "кто мешает", или "замешивает"? Как всё сложно порою бывает :)

Включение (с заменой) нового VFS добавит рейзер4 и поломает все остальные ФС. Видимо такая революция никому не нужна. Кому, нужен именно рейзер, пока смирятся с наличием двух VFS в ядре.

>По-русски говоря -- они уперлись лбами и уже больше года дале не >движется.

Бред, почитайте lkml, а не opennet.ru и откройте,
что как раз в данный момент идет обсуждение
того как будет выглядеть batched write,
который нужен reiser4 в VFS, также эта идея пришлась по вкусу
разработчика fuse.

>Бред, почитайте lkml, а не opennet.ru и откройте, что как раз в данный момент идет обсуждение того как будет выглядеть batched write, который нужен reiser4 в VFS, также эта идея пришлась по вкусу разработчика fuse.

batched write, кстати, не из reiser4 вытащили, а как отдельный механизм записи, который был бы полезен всем.

Но только что-то не видно, чтобы reiser делал движения в сторону включения этого механизма в основное ядро.

>fghj **** (*) (30.06.2006 13:18:31)

>batched write, кстати, не из reiser4 вытащили, а как отдельный >механизм записи, который был бы полезен всем.

но первоночально идея была предложена Reiserом

>Но только что-то не видно, чтобы reiser делал движения в сторону >включения этого механизма в основное ядро.

посылка патча в lkml, просьба включить в -mm ветку,
это теперь не движение в сторону включения?

> В общих чертах суть их недовольства заключается в том, что reiser4 не только мало использует generic-код, предназначенный для автоматизации рутинной работы, наличиствующей почти во всех ФС (типа generic-read, generic-write, тесно интегрированные со страничным и блочным кэшами), но и своими плагинами вносит в ядро избыточную функциональность, уже реализованную в слое VFS. Где-то они, конечно, правы. Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут в основном благодаря отказу от их использования. По-русски говоря -- они уперлись лбами и уже больше года дале не движется.

Движеться потихоньку, вот недавно Ганс отсылал изменения в VFS, которое в их фаловой системе используется в обход VFS, на что Линус ответил, что мы готовы включить это дело, если найдутся еще пользоватли среди файловых систем входящих в ядро.

Мне кажется тут все просто, основные разработчики не хотят включать в ядро систему, которая вроде как использует VFS, а вроде как и переопределяет его почти весь под себя. В тоже время Ганс зарабатывает на этой системе и естественно от включения в основную ветку он только выигрывает.

Я лично на стороне разработчиков ядра, так как перенос ряда фич из рейзера в VFS улучшит производительность/функциональность остальных систем.

> но первоночально идея была предложена Reiserом

другие fs это *уже давно* делают используя существующее api. ханс опять изобретает велосипед.

>В тоже время Ганс зарабатывает на этой системе и естественно

В последнем интервью, которое я читал, у него было долгов чуть ли не на четверть лимона, так что здорово он зарабатывает на reiser4.

Вы посмотрите вначале кому я отвечал и что там человек спрашивал. Дальнейшая судьба рейзера в ванилле и подвижки для этого -- отдельная песня.

>другие fs это *уже давно* делают используя существующее api. ханс >опять изобретает велосипед.

вообще-то предложенное решение не возможно реализовать с помощью уже существующего API, так что вы явно не в теме,
в противном случае никто бы его патчи в -mm не стал бы принимать.

>>batched write, кстати, не из reiser4 вытащили, а как отдельный >механизм записи, который был бы полезен всем.

>но первоночально идея была предложена Reiserом

Но не из их файловой системы. Т.е. это просто полезное нововведение, заслуга Reiser'a или его людей, но не reiserfs4.

>>Но только что-то не видно, чтобы reiser делал движения в сторону >включения этого механизма в основное ядро.

>посылка патча в lkml, просьба включить в -mm ветку, это теперь не движение в сторону включения?

Конечно нет. Для того, чтобы патч включили, он должен быть одобрен многими людьми, бросание строчек кода с требованием включить ни к чему хорошему не приведет.

>fghj **** (*) (30.06.2006 13:46:36)

> вообще-то предложенное решение не возможно реализовать с помощью уже > существующего API, так что вы явно не в теме, > в противном случае никто бы его патчи в -mm не стал бы принимать.

не льстите себе

>Но не из их файловой системы. Т.е. это просто полезное нововведение, заслуга >Reiser'a или его людей, но не reiserfs4.

да неужели, а можно узнать критерии того что из reiser4 а что нет?

этот патч был предложен, т.к. экономит 50% CPU для reiser4

>Конечно нет.

да неужели? т.е. теперь когда хочешь включить свой патч в ядро,
надо начинать не с поссылки его в lkml и Мортону?

может вы объясните новый способ? рассылка распечаток всем кто перечислен в MAINTAINERS?

>не льстите себе

может тогда ты приведешь где уже реализован batch write ( не prealloc)?

> может тогда ты приведешь где уже реализован batch write ( не prealloc)?

читаем lkml: "For some filesystems (e.g. XFS) only reservations for delayed allocations are performed in this path so it doesn't really matter. For not so advanced filesystems batching these calls would definitly be very helpful."

думаем про какую fs сказано "not so advanced" :)

batch write - это костыль для хромой reiser4

>>Но не из их файловой системы. Т.е. это просто полезное нововведение, заслуга >Reiser'a или его людей, но не reiserfs4.

>да неужели, а можно узнать критерии того что из reiser4 а что нет?

>этот патч был предложен, т.к. экономит 50% CPU для reiser4

there are times when due to the limited size of RAM you want to do some things once per WRITE_GRANULARITY, where WRITE_GRANULARITY is a #define that defines some moderate number of pages to write at once. This code empirically proves that the generic code design which passes 4k at a time to the underlying FS can be improved.

Что здесь является reiserfs specific? Люди работают над файловой системой, при этом обнаруживают, что в generic коде можно повысить производительность.

>>Конечно нет.

>да неужели? т.е. теперь когда хочешь включить свой патч в ядро, надо начинать не с поссылки его в lkml и Мортону?

>может вы объясните новый способ? рассылка распечаток всем кто перечислен в MAINTAINERS?

Не нервничайте вы так... Дышите глубже.

Для принятия патча в ядро нужно не только показать, что он создает некоторые преимущества, но и что эти преимущества достаточны для включения патча. Тот же reiserfs4 - по некоторым тестам он обошел все другие ФС, но при этом никто не собирается его включать в mainline, т.к. он слишком много ломает. Так же и этот патч - чтобы его включили, нужно проделать большую работу по доказательству того, что это _действительно_ корректный подход, что при этом ничего не сломается, что _действительно_ xfs и fuse станут быстрее работать и т.п. Господин Рейзер же показал всем код и поступил как обычно - не нравится, не берите, он ничего по этому поводу предпринимать не будет.

>fghj **** (*) (30.06.2006 18:15:06)

>Не нервничайте вы так... Дышите глубже.

я нервничаю? пятница, впереди выходные с чего мне нервничать?

>Так же и этот патч - чтобы его включили, нужно проделать большую работу по >доказательству того, что это _действительно_ корректный подход

мы откланяемся от темы,
ваше утверждение было что Рейзер ничего не делает для включения,
я заметил что он сделал первый шаг послал в lkml и Мортону патч,

конечно это не тоже самое что набрать "cvs commit" и enter,
но это первый и _необходимый_ шаг и он сделал его,

так что неверно говорить что он ничего не делает,
и он сделал не только этот шаг.

>Господин Рейзер же показал всем код и поступил как обычно

вообще-то это ложь.

он
а)объяснил зачем это нужно
б)нашел кому еще это нужно, fuse, еще одну фс,

так что в конце Мортон сказал, ладно я вижу это многим надо покажите
код,
так что сейчас идет обсуждение содержания, а не включать/не включать.

>Что здесь является reiserfs specific? Люди работают над файловой системой, при >этом обнаруживают, что в generic коде можно повысить производительность.

никто не говорил что это reiserfs specific,
я говорил что идея пришла из reiser4 кода.

>>Так же и этот патч - чтобы его включили, нужно проделать большую работу по >доказательству того, что это _действительно_ корректный подход

>мы откланяемся от темы, ваше утверждение было что Рейзер ничего не делает для включения, я заметил что он сделал первый шаг послал в lkml и Мортону патч,

>конечно это не тоже самое что набрать "cvs commit" и enter, но это первый и _необходимый_ шаг и он сделал его,

>так что неверно говорить что он ничего не делает, и он сделал не только этот шаг.

Демагогия? Он протестировал свой патч на чем-нибудь еще? Он доказал, что он ничего не ломает? А самое главное - он _собирается_ хоть что-то еще предпринять, чтобы включить его в ядро. Что-то подсказывает, что он ровным счетом ничего не станет делать - как обычно.

>>Господин Рейзер же показал всем код и поступил как обычно

>вообще-то это ложь.

>он а)объяснил зачем это нужно б)нашел кому еще это нужно, fuse, еще одну фс,

Это не он нашел, а ему показали.

>так что в конце Мортон сказал, ладно я вижу это многим надо покажите код, так что сейчас идет обсуждение содержания, а не включать/не включать.

Мортон принимает в -mm все, что угодно. Но Ханс даже повторно посылать ничего не стал (по крайней мере пока, хотя обещал в конце недели).

>fghj **** (*) (30.06.2006 18:44:31)

>. Но Ханс даже повторно посылать ничего не стал (по крайней мере пока, хотя >обещал в конце недели).

вообще-то вчера прислал

>>Но Ханс даже повторно посылать ничего не стал (по крайней мере пока, хотя >обещал в конце недели).

>вообще-то вчера прислал

В linux-fs@ не было. Последнее письмо от 20 июня.

>Мортон принимает в -mm все, что угодно.

1)Все-таки было бы неплохо двигаться полегче на поворотах,
отнюдь не все, но то что может принять плохо оттестированное это факт.
2)Если не возникает замечаний, а по крайней мере разработчики xfs, fuse и lustrefs считают что это было бы неплохо иметь, то после включения в -mm можно как-то обнаружить в почтовом ящике:
This patch was dropped because it was merged into mainline

>В linux-fs@ не было.

Напишите Рейзеру, чтобы вам в следущия раз копию посылал.

>Последнее письмо от 20 июня.

http://lkml.org/lkml/2006/6/29/238

>>Мортон принимает в -mm все, что угодно.

>1)Все-таки было бы неплохо двигаться полегче на поворотах, отнюдь не все, но то что может принять плохо оттестированное это факт.

>2)Если не возникает замечаний, а по крайней мере разработчики xfs, fuse и lustrefs считают что это было бы неплохо иметь, то после включения в -mm можно как-то обнаружить в почтовом ящике: This patch was dropped because it was merged into mainline

Как я заметил выше, as is batched write ни fuse, ни xfs не помогает. Об этом и сам Рейзер говорил. Хотя потом резко менял точку зрения.

Reiser: Forgive myn utter ignorance of fuse, but does it currently context switch to user space for every 4k written through VFS?

Reiser: I would think that batched write is pretty essential then to FUSE performance. If we could then get the glibc authors to not sabotage the using of a large block size to indicate that we like large IOs (see thread on fseek implementation), reiser4 and FUSE would be all set for improved performance. Even without glibc developer cooperation, we will get a lot of benefits.

Dilger: I believe XFS would benefit from delayed allocation... With the caveat that I didn't see the original patch, if this can be a step down the road toward supporting delayed allocation at the VFS level then I'm all for such changes.

Итого: патч как есть особой пользы in-kernel ФС не приносит, вреда возможно тоже. На основании этого патча можно сделать значительные улучшения, но будет ли Рейзер делать что-то, что может улучшить производительность конкурента (XFS)?

>Хотя потом резко менял точку зрения.

Ну надо же ему убедить всех что это нужная вещь, а тут союзники появились,
и он начинает к ним подлизываться.

>йзер делать что-то, что может улучшить производительность конкурента (XFS)?

я думаю стоимость поддержки вне ядра, и возможность бить себя пяткой в грудь и говорить reiser4 в ядре все-таки перевесят возможность конкуренции и гонор Рейзера.

>Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут в основном благодаря отказу от их использования.

Неоптимально, пусть перепишет. Я еще помню, как третий не пускали из-за ужасного синтаксиса и не следования стандартам написания кода в ядро.