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

>глупые виндоузятники, которые за каждый байт данных удавиться готовы

удавились бы они быстрее...

Будет весело, если в середине этого дела процесс ёкнется ;-)

http://lwn.net/Articles/99260

Вот обидетсо Райзер и уйдет в некрософт работать.. :)

нет, данные просто двигаются внутри одного и того же раздела. На разделе создается файл, который тоже монтируется как раздел. Перенося данные формально с одного раздела на другой, на самом деле мы двигаем данные в границах одного и того же раздела.

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

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

>для перевода существующей ext2/3 на ext4 вполне достаточно нарисовать
>отдельный конвертер

в данный момент, для перевода ext3 на ext3 с поддержкой терабайтовых дисков достаточно всего лишь смонтировать ext3 с особой опцией.

Мне плевать, если он будет продолжать делать свою классную файловую систему под GPL, он может хоть на панели работать!

> Мне плевать, если он будет продолжать делать свою классную файловую систему под GPL, он может хоть на панели работать!

папрашу не путать MS Windows Vista и панель - это две разные платформы.

// wbr

Страно как то все звучит. В анонсе файловой системе говорят только о ее совместимости с одной из существующих ФС, что вопрос далеко не самый первостепенный в этом вопросе.

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

На самый крайний случай, могли сказать хоть о том, какие проблемы присущие текущему поколению ФС они собираются решать.

Мне это паралельно :-) если ФС продолжает развиваться. ;-)

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

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

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

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

> Я не понял зачем ext4 нужна, потому что в рамках прежней архитектуры ничего принципиально нового и лучшего не будет. Лучше бы довели до ума и включили в ядро reiserfs.

Ой, на дворе уже чуть ли не конец 2006 года, а вы все никак с 2.2 ветки не слезете? ;)

>нет, данные просто двигаются внутри одного и того же раздела. На разделе создается файл, который тоже монтируется как раздел.

Ну дык он же (файл) конечного размера. В него больше чем он сам + место под таблицы/журнал не напишешь.

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

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

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

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

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

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

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

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

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

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

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

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

там как то создается разреженный файл большого размера(sparce file). подозреваю, что под него можно сразу все место на диске не выделять. Т.е он виртуально имеет огромный размер, а рельно занимает столько места, сколько записано.

Размер файла имеет значение только для монтирования его как устройства, что бы постоянно не перемонтировать. Но даже в этом варианте, можно переодически какими то кусками менять размер файла и перемонтировать устойство.

>>нет, данные просто двигаются внутри одного и того же раздела. На разделе создается файл, который тоже монтируется как раздел.

>Ну дык он же (файл) конечного размера. В него больше чем он сам + место под таблицы/журнал не напишешь.

Хотя с помощью файла с "дыркой" мне таки удалось "обмануть" систему так что похоже так можно делать .... но под журнал и таблицы таки должно быть свободное место.

> Фич пока не придумали.

"Шеф, мы изобрели новое лекарство! Осталось найти болезнь, которую оно лечит!".

Писец. Какой смысл начинать разработку новой ФС, если неясно, нах она вообще нужна? Имитация бурной деятельности и пеар?

на родительской фалухе данные уходят же... на образе добавляются, то есть места свободного может быть по идее хоть 10%

>там как то создается разреженный файл большого размера(sparce file). 

Угу. Это работает.
dd if=/dev/zero of=/tmp/XXX/test seek=10000 bs=1M count=1;mkfs -t ext2 /tmp/XXX/test; sudo mount /tmp/XXX/test -o loop -t ext2 /mnt/loop ;df -H

Файловая система       Разм   Исп   Дост  Исп% смонтирована на
/dev/hda5               45G    42G   2,2G  96% /
/tmp/XXX/test           11G    21k   9,8G   1% /mnt/loop

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

2Banshee (*) (30.06.2006 14:19:26)

Разобрался ;) Мне сначала показалось что образ бы пришлось растягивать "н а лету" :) Совсем забыл что есть же дырявые (sparce) файлы ;)

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

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

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

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

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

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

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

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

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

>Вот обидетсо Райзер и уйдет в некрософт работать.. :)

И тогда венде точно.... :)

> Писец. Какой смысл начинать разработку новой ФС, если неясно, нах она > вообще нужна? Имитация бурной деятельности и пеар?

это просто вы дурак и за темой не следили.

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

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

ну вообще вроде как сказано, что это просто развитие ext3. А потом всё соберут и повесят новый лого.

> Писец. Какой смысл начинать разработку новой ФС, если неясно, нах она вообще нужна? Имитация бурной деятельности и пеар?Писец. Какой смысл начинать разработку новой ФС, если неясно, нах она вообще нужна? ? Имитация бурной деятельности и пеар?

ну почему, почему вы такие тупые и ленивые? оригинал прочитайте _внимательно_. хотя бы первые строки:

" Given the recent discussion on LKML two weeks ago, it is clear that many people feel they have a stake in the future development plans of the ext2/ext3 filesystem, as it one of the most popular and commonly used filesystems, particular amongst the kernel development community."

да пребудет с нами ufs2!!! но за линуксоидов искренне рад!

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

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

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

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

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

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

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

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

>да пребудет с нами ufs2!!! но за линуксоидов искренне рад!

тото *BSDны мечтают о xfs/jfs, на худой конец zfs.

> может тогда ты приведешь где уже реализован 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)

думаем еще раз и понимаем, что в случае delayed allocation, никаких batch write не нужны - prepare_write и commit_write практически пустые получаются, только резервирование блоков и модификация i_size.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>думаем еще раз и понимаем, что в случае delayed allocation, никаких batch write >не нужны - prepare_write и commit_write практически пустые получаются, >только резервирование блоков и модификация i_size.

Во-первых текущее delayed allocation вунуждует fs делать это для каждой
страницы, вместо для куска который дал write

> The current ->prepare_write() interface shows its limits when having to
>do hundreds of thousands (millions, even) of ->prepare_write() calls per
>second.

во-вторых ваще заявление было

а)есть фс которая реализует что-то подобное,
согласен xfs
б)есть общее API для этого,
не согласен, один из текущих мантейнеров:

Basically, the only thing really needed from the VFS/VM is a method of tagging
delalloc (or unwritten) pages so that the writepage path knows how to treat
the page being written

в)Ханс Рейзер изобретает велосипед,

тогда объясните почему и разработчики XFS, и Мортон, и разработчик FUSE,
говорят что неплохо бы это иметь?

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

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

>в)Ханс Рейзер изобретает велосипед,

>тогда объясните почему и разработчики XFS, и Мортон, и разработчик FUSE, говорят что неплохо бы это иметь?

Чтобы это помогло FUSE, последнюю нужно исправить в некоторых местах, на что даже Рейзес сначала говорил. XFS от этого никак не выиграет. Dilger говорил о delayed allocation, которое может основываться на этом патче.

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

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

В 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 в ядре все-таки перевесят возможность конкуренции и гонор Рейзера.