izvrat. i bez togo eith FS razvelos'... luchsheb chtonit' universal'noe pridumali : odno pod vsye. standart kakoy nit'. a tak klepayut vse komu ni len'. pridumayut noviy algorithm, i davay ogorod ne vdol', a po perek perekapivat'......... Kyros

Интересное решение, посмотрим, что из него вырастет. В "солидных" компаниях такой самодеятельности не позволили бы (как же, это очень рисковано и можно потерять кучу времени и денег), а тут все-таки open source и free software, тут все можно :) Если получится что-нибудь лучше, чем все эти "стабильные и проверенные" подходы журнальных систем, то я буду очень рад.

Блин...

Ну ладно, хочется народу.

Вот только во Фришке не нужны ни журналируемые FS, ни эти новые идеи, все работает устойчиво (и даже быстрее чем банальный async) уже весьма давно. Soft-updates это знаете ли большой рулеzzz!

Гыгыгы. "фришке не нужны эти фс". Очень умный анонимус это писал, явно :)

Вот бы еще кто взялся реализовывать ту же идею, что была в файловой системе Spiralog... Журналирование без оверхеда - это стильно!

Вот как раз TUX2 и не требует оверхеда - самого журналирования как такового и нет (нет журнала транзакций). Просто гарантируется, что все метаданные системы можно точно восстановить в любой момент. Хотя как писали на слэшдоте, журналируемые ФС не имеют теоретического обоснования 100%-ой гарантии если на винте врублен буфер записи - при вырубании питания в момент когда он (буфер на _винте_) еще не опустошен будет потеря информации. Если вообще винт выживет :)

2 Casus

Слышь, Casus, ты хоть знаешь, что такое soft-updates? Если нет, то послушай. И зачем наезжать?

Традиционно практически все UFS (включая FFS и ext2fs) были устроены так, что "лениво" записывалось лишь содержимое файлоов, любое же изменение метаданных тут же влекло за собой запись на носитель со всеми вытекающими отсюда performance penalties. Радикальное решение - записывать metadata асинхронно, как и содержимое файлов. Как следствие - performance increases dramatically, но если произойдет любой сбой в работе, you can get a totaly screwed filesystem as as result.

Полагаясь на то, что такая ситуация - все-таки большая редкость (когда файлухе ну уж очень хуево), линухи по умолчанию монтируют filesystems in async mode, while FreeBSD mounts 'em sync (это к вопросу некоторых не очень умн^H^H^Hискушенных людей, "а почему фришка настолько сосет у линуха, когда дело касается дисковых опрераций?"). Не нравится - меняй, только потом на себя пеняй, если файлуху придется рекриэйтить.

Затем я вас отошлю к этому труду: Gregory R. Ganger and Yale N. Patt, "Soft Updates: A Solution to the Metadata Update Problem in File Systems", CSE-TR-254-95, August 1995" from the appendix of a University of Michigan technical report. Здравый чувак Marshall Kirk McKusick, на основе этого и создал то, что мы теперь знаем как soft-updates (за детальной информацией смотри http://www.mckusick.com/softdep/).

Вот отрывок оттуда, сам читай:

Traditionally, filesystem consistency has been maintained across system failures either by using synchronous writes to sequence dependent metadata updates or by using write-ahead logging to atomically group them. Soft updates, an alternative to these approaches, is an implementation mechanism that tracks and enforces metadata update dependencies to ensure that the disk image is always kept consistent. The use of soft updates obviates the need for a separate log or for most synchronous writes. Indeed, the ability of soft updates to aggregate many operations previously done individually and synchronously reduces the number of disk writes by 40 to 70% for file-intensive environments (e.g., program development, mail servers, etc.). In addition to performance enhancement, soft updates can also maintain better disk consistency. By ensuring that the only inconsistencies are unclaimed blocks or inodes, soft updates can eliminate the need to run a filesystem check program after every system crash. Instead, the system is brought up immediately. When it is convenient, a snapshot is taken and a background task can be run on on that snapshot to reclaim any lost blocks and inodes. The use of a snapshot allows normal filesystem activity to continue concurrently.

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

А ты, если о фряхе только понаслышке знаешь, то и не фиг :-(

Anonymous,
Soft-updates это всего лишь подход к оптимизации того самого sync mount.
В каком-то смысле async syncing. Более стабильно файловая система особо не будет.
Будет как упомянает статья всего-то в 1,5 раза быстрее. IMHO рулезности особой нет.
Журнальные файловые системы зачастую в 10 раз быстрее и более стабильны.
Это конечно команде БЗДи решать как они будут развиваться. Нужны ли им более
современные файловые системы или нет. Лично у меня к ним интерес пропал.
Не люблю застой.
То что в 2.4 будет LVM и xfs по моему большая победа.
Чем больше идей - тем больше выбор, а возможность выбирать это роскош.
Все сводится к свободе выбора.

2 Tima

Короче упертый линуховец писал... млин..

> Soft-updates это всего лишь подход к оптимизации того самого sync mount

Скорее, все же async mount. Хотя несколько сотен килобайт исходного кода позволяет говорить о чем-то большем, нежели просто "оптимизация". Смотря что называть оптимизацией конечно...

> Более стабильно файловая система особо не будет

Смотря что ты называешь стабильностью. Для меня это то, что в случае краша я почти со 100% вероятностью получу consistent filesystem, and not the total mess. И мне не придется тратить туеву хучу времени на восстановление хоть каких-нить данных (что весьма вероятно при async), особенно когда такое неприятное событие происходит на машине, очень интенсивно юзающей диск.

> Будет как упомянает статья всего-то в 1,5 раза быстрее

Скорость будет примерно как у async, а на некоторых задачах даже быстрее (например, при пересборке ядра).

> Журнальные файловые системы зачастую в 10 раз быстрее и более стабильны.

То что более стабильны - наверняка. А вот насчет скорости... Впервые такое слышу. По логике вещей, как раз в скорости-то, неговоря уже о прочим, journaling filesystems должны уступать async'у и soft-update'ам. В идеале - самое быстрое async (и самое небезопасное) тогда как асинк, не ведущий никакого журнала, записывающий все что заблагорассудится когда заблагорассудится, может на порядок уступать journ'ам создающим дополнительный (и весьма не маленький) overhead? Ты б хоть бенчмарки какие привел, что-ли...

> Это конечно команде БЗДи решать как они будут развиваться

Ага, и они развиваются! Скоро SMP ихний будет - не чета линуховому :)

> Не люблю застой

Никто не любит. Только FreeBSD не застой все-таки будет, вот сколько народу постепенно с linux на него переползает... видать не просто так.

> Чем больше идей - тем больше выбор, а возможность выбирать это роскош.

Кто ж спорит?..

> Короче упертый линуховец писал... млин..
Убежденный. ИМХО здесь ты анон-ус упертый бздельник.
Как вы к нам так и мы к вам.

>Скорее, все же async mount. Хотя несколько сотен килобайт исходного кода позволяет говорить о чем-то большем, нежели просто
>"оптимизация". Смотря что называть оптимизацией конечно...

Для оптимизации и модернизации такого старья как UFS IMHO надо горадо больше чем 100k.

>Смотря что ты называешь стабильностью. Для меня это то, что в случае краша я почти со 100% вероятностью получу consistent
>filesystem, and not the total mess. И мне не придется тратить туеву хучу времени на восстановление хоть каких-нить данных (что
>весьма вероятно при async), особенно когда такое неприятное событие происходит на машине, очень интенсивно юзающей диск.

100% вероятности не будет. Ошибок в лучшем случае будет немного больше чем и при sync i/o.
Бесспорное приемушество это fast power failure recovery.
Абсолютно не адресуется hardware failure как и в UFS.
К примеру, failure на / партишн привердет к локу системы.

>Скорость будет примерно как у async, а на некоторых задачах даже быстрее (например, при пересборке ядра).

50-70% по оценкам автора. ИМХО это в 1,5 и немного более раз.

>То что более стабильны - наверняка. А вот насчет скорости... Впервые такое слышу. По логике вещей, как раз в скорости-то,
>неговоря уже о прочим, journaling filesystems должны уступать async'у и soft-update'ам. В идеале - самое быстрое async (и самое
>небезопасное) тогда как асинк, не ведущий никакого журнала, записывающий все что заблагорассудится когда заблагорассудится,
>может на порядок уступать journ'ам создающим дополнительный (и весьма не маленький) overhead? Ты б хоть бенчмарки какие
>привел, что-ли...

Охотно, но тон твой не особо располагает.
"Доморошенная" jfs ReiserFS выдает следуюшие результаты против той же ufs Ext2.
http://devlinux.com/projects/reiserfs/
Из моего личного годвого опыта использования ее такие операции как create и stat
реально в 10 раз быстрее. delete тоже внушительно быстрее, примерно в 5 раз.
Единственна раздажительная черта reiserfs которая является причиной его отсутсвия
в релизах ядра это все еще имеюшие место изменения в формате журнала.
Это означает что при очередном апгрейде приходится переформатировать fs.

XFS и JFS таких проблем не имеют потому как все алгоритмы отработаны и оттестированы.


>Ага, и они развиваются! Скоро SMP ихний будет - не чета линуховому :)

Желаю им всего хорошего. Зная сколько времени команде БЗДи понадобилось для
разработке SYSV4 и POSIX думаю на написание приличного SMP уйдет около 4х лет.
Проект БЗД не рождал ничего интересного с того момента как он покинул стены Беркли.
Реально единственное приемушество которым обладает БЗДи до сих пор это скоростной TCP stack.
Спасибо команде Беркли 15 лет назад. На этом все заканчивается.


>Никто не любит. Только FreeBSD не застой все-таки будет, вот сколько народу постепенно с linux на него переползает... видать не
>просто так.

Не думаю чтобы БЗДи получило какую-то пользу от людей которые перелазят с Windows на Linux а с Linux на БЗДи...
Такие в Linux обществе не нужны :) Забирайте.
Не нравится Linux - полно альтернатив.
Linux не для глупых, слабодушных или сомневаюшихся. Как и БЗДи впрочем.

>Кто ж спорит?..

по крайней мере мы хотябы в чем то согласились :)

Хм.. Рейзер это конечно кайфная файлуха. Вот только AFAIR квот пока не поддерживает, что не есть гуд.

Посмотрел benchmarks. В целом действительно быстрее, только не в 10 раз и не всегда.

На production серверах рут обычно в ридонли монтируется..

(сорри что не цитирую)

>Хм.. Рейзер это конечно кайфная файлуха. Вот только AFAIR квот пока не поддерживает, что не есть гуд.
ИМХО квоты нужны только на "открытых" серверах, с кучей пользователей которых нужно контралировать.
Например университетские сервера.
Такие ситуации в принципе редкие.
Mне еще никогда не приходилось внедрять квоты и им подобные вещи в систему. Не было надобности.

>Посмотрел benchmarks. В целом действительно быстрее, только не в 10 раз и не всегда.
Я и говорил что в некоторых ситуциях (зачастую) в 10 раз выше, а когда и в 3-5 раз.
В обшем внушительно быстрее.
Из-за обидного "under construction" статуса reiserfs на / или /usr ее не поставишь.
А вот на /tmp /var/app/logs /rootcvs и тому подобном reiserfs работает неплохо.


>На production серверах рут обычно в ридонли монтируется..
Абсолютно справедливо. В принципе все кроме /tmp и некоторых участках /var в которые
пишутся логи все в ro замаунтированно. Однако лишь немногие системы могут перенести
когда задымится /. Linux/BSD лочатся так что потом приходится ехать на сайт и
восстанавливать все по частичкам, Solaris лочится если не купили Veritas за XXk$.
Veritas нормально держится. То есть если у меня летит primary disk я спокойно могу
ребутнутся с зеркала без большого секса и поездки на сайт к машине.
Ждем когда поспеют такие решения для open *nix.

Люблю мир :)

Вот интересно, линуксовые сайты бздисты читают чтобы в форуме погадить? Ладно, к чертям ругань. По делу: после анонса tux2 в linux-kernel один из подписчиков задал вопрос "а почему бы вам просто не реализовать soft-updates?" На что автор tux2 сказал "а нафига? нафига нам 99% вероятность восстановления, если можно сделать 100%?". Вот и нету soft-updates, "они пошли другим путём".

2 tima_

Просвети, пожалуйста, про этот veritas, что за зверь?
А то я только такую швейную машинку знаю...;))
Можно мылом на ALEZHU@MAIL.ru.
Если есть время и желание, конечно...

alezhu.

Вроде надёжность журналирумых систем верна только в том случае, если запись на винт идёт в том порядке, в каком пишет драйвер. Но для большиства современных винтов имеет место буферизированая запись - т.е. контроллер может инвертировать порядок записи двух последовательных операций для оптимизации. Кто-нибудь знает как с этим на bsd UFS, ReiserFS, TUX2FS ?

Tima, посмотри еще раз внимательно на бенчмарки, и заметь одну тонкость: ext2fs 4k block упоминается лишь в одном тесте и по производительности она почти не уступает reiserfs. Так вот, проведи все тесты с ext2fs 4k block, и ты увидишь, что секс с reiserfs не стоит своих преимуществ. На mysql (читай - любых БД) reiser проигрывает. И что остается? Только быстрый старт после краша и куча мелких подводных камней, ожидающих тебя в самых неожиданных местах. Так что нефиг рассказывать сказки. Кроме того, многие приведенные тесты стоят там уже года полтора без изменений. А ты поробуй то же самое прогнать со свежими ядрами 2.4.0-ххх. Будешь приятно удивлен деградацией по всем пунктам.

2 Casus

Слушай внимательно, объясню, зачем *я* читаю "линуховые" сайты.

1. Конечно и безоговорочно, самый здравый новостной сайт это /. Тем не менее, всегда интересно, что думают по тому или тому поводу наши парни :) И потом, на /. info/noise все же весьма низок, во всяком случае по сравнению с LOR

2. Из всех линуховых сайтов я читаю *только* LOR. Мне весьма нравится (и по оформлению и по содержанию). Новости конечно иногда с запозданием приходят... Но это фигня. Можно узнать что-то новое/пообщаться с умными людьми (небойся, не про тебя), скриншоты посмотреть... и все на одном сайте. А вот искать информацию по интересующему вопросу (если уж очень надо) нужно все-таки в соответсвующих конфах, а не в WWW :-)

3. Так повелось.

эээ... типа... это ext2 то быстрее для MySQL????

ГЫ. 1) reiser у меня уже давно и успешно живет полностью на всех разделах. НА ВСЕХ. 2) MySQL ОЩУТИМО быстрее работает на reiser. (особенно с notail и noatime) И не надо ля-ля. Тут МайСиквел работает на пределе возможностей - спайлог знаете контору? Ну так вотя тут один из главных админов. И все живет на ЛИНУКС. А не на FreeBSD. И не на солярисе. Т.к. они просто падают от такой нагрузке... Такие вот ватрушки.

ГЫ. А как же MySQL у тебя быстрее, когда по тестам самого рейзера оно медленнее? Ну и уж раз назвался груздем, то скажи, что у тебя за ядро, и какая версия reiserfs.

Интересно, а как делают rootfs readonly без devfs? В /dev ведь чего-то писаться должно.

Veritas (www.veritas.com) занимается продажей LVM/HAfs на Solaris.
По поводу reiserfs с ядром 2.2.x могу сказать следующее.
Бенчмарки у Reiserа староваты. От 4k блок в ext2 результат изменится мало.
4k блок разумен для мелкого размера партиций, именно поэтому 8k блок сейчас
является стандартом (не спроста, правда?). 4k блок абсолютно неэффективен на
гигабайтных партициях и я думаю там reiserfs даст 20 раз форы.
Секс с reiserfs случается только в одном месте - updates.
Бенчмарки с mysql у Рейзера приведены лишь для демонстрации его концепции, что
reiserfs (как и любая журнальная) это "fs с SQL взгладом на вещи" поэтому
SQL поставленный на SQL особой производительности не принесет. А вот работа
с простыми лог файлами ускорится значительно.

Тима, хорош свистеть. Где ты видел ext2fs 8К block? Чем ты создаешь такую файловую систему? Последние e2fsprogs-1.19 такого не позволяют. Максимум - 4096 байт.

Сново физдение началось.
Block size спутал Linux с Солярой.
Маньюал по newfs
"-b bsize The logical block size of the file system in bytes
(either 4096 or 8192). Thedefault is 8192. The sun4u architecture
does not support the 4096 block size."
Маньюал по mke2fs
"-b block-size
Specify the size of blocks in bytes. Valid block size vales are
1024, 2048 and 4096 bytes per block. If omitted, mke2fs block-size
is determined by the file system size and the expected usage of the
filesystem (see the -T option)."
А вообще если речь идет об оптимизации UFS-подобных систем то одно из
наиболее цензурных обьяснений вещей имеется в Sun Disk Suite Configuration Guide.
http://docs.sun.com:80/ab2/@LegacyPageView?toc=SUNWab_163_1:/safedir/space3/coll 1/SUNWssie/toc/DISKSUITEREF:1135;bt=Solstice+DiskSuite+4%2E1+Reference+Guide;ps= ps/SUNWab_163_1/DISKSUITEREF/07.Configuration_Guidelines#9
Вся арифметика вычисления парамеров описана на ссылке выше.
Как справедливо замечает mke2fs разумный block size выбирается по РАЗМЕРУ ФАЙЛОВОЙ СИСТЕМЫ.
На мелкой fs 4096 блок будет работать ХУЖЕ чем 2048.

Весь смысл предыдушего поста был - Хорошь физдеть о том что простая установка
блока в 4096 послужит поводом к фантастическому улучшению производительности
и перекроет весь тот SQL подобный механизм в реализуемый в журнальных fs.
Хотя бы по простой причине что если бы это было так то фиг кто-нибудь даже ДУМАЛ
о написании журнальных fs.

Да епрст, ты попробуй сначала, потом теории разводить будешь. 4К блок дает минимум полуторакратный прирост скорости на файловых операциях. Проверено. Linus вообще не использует ничего, кроме 4K блок для e2fs. Тоже о чем-то говорит.

Ты мозги не пудри. Основная причина по которой пишут журнальные фс - сохранность данных и быстрое восстановление после краша. Мы же говорим о скорости.

anonymous,
Я тебе кажется отпостил ссылку на документ РАССКАЗЫВАЮЩИЙ об оптимизации
UFS подобных файловых систем. Пока не прочтешь и не врубишься пиздеж о
размере блока прекращай.
Мы не в Китае и плевать мне хотелось на магические числа вроде 4096.
Какого х подымать дебошь что 2048 плохо а 4096 хорошо.
Как ты видишь ВСЕ современные системы Solaris (sun4u) имеет размер блока 8k
так что, это значит что там у них в 1,5 раза быстрее fs?
Тем более на БОЛЬШОЙ файловой системе линукс АВТОМАТИЧЕСКИ поставить блок в 4к
как говорит его маньюал.
А заявления типа "попробуй Баунти" потом расскажи это на уровне 12 летнего паскалиста.

У Сопляриса она как раз в полтора раза медленнее. Ему этот размер блока, что мертвому припарка.

Что только подчеркивает всю абсурдность разговора о том что 2 плохо а 4 хорошо.

Журнальные fs не только обещают быть более устойчивыми но и быстрыми.
Create,seek и delete будут быстрее с журналом.

Ставить reiserfs на все диски значит что при очередной попытке апгрейта ядра
с новой версией fs нужно будет переставлять всю машину.

А что, reiser всех уже порвал? Какое-то время назад вроде как говорили про конкуренцию между reiser'ом, xfs, jfs, ext3fs... Где же они сейчас?

а вот вроде в нетBSD своя Logging File System, это я так понимаю все-таки типичный UFS с журналом?

Да в общем ничего особого в reiserfs нет.
Просто до сих пор работая с 2.2.x ядром альтернатив нет.
XFS в 2.4 и это только обнадеживает.
JFS портируется не особо интенсивно.
EXT3 не радует. Не верю я в успех файловых систем построенных на старых мерках.
Мой личный план перейти на xfs когда появится удовлетворительная версия 2.4.

Согласен. XFS - это круто. По крайней мере на IRIX работает хорошою

На ирисках многое работает хорошо и даже очень, хоть и говорят, что последнее время ося хиреет :( а все из-за линухов, млин..

2 Tima_ А что 2.4.0-test9 для xfs не подойдет уже?

2.4.0-test9 подойдет и для lvm+xfs замечательно.
Вот продолжаю ждать пока i/o в 2.4 ветке доведут хотябы примерно до 2.2 уровня.
Единственное что меня сейчас останавливает это не вполне удовлетворительная
производительнось i/o.

2.4.x отстой отстоем..

А что там с I/O в 2.4?

А что там с I/O в 2.4? Тестов dbench испугался? Иль ещё чего?

;) Ребят, я и мои знакомы плюются, когда грузятся из 2.4.0-test9 назад в 2.2. test9 работает на порядок быстрее и с IO и с VM чем 2.2. Причем идут туда не чтобы работать, а чтобы показать, какой отстой 2.2. Запуск процессов в 2.4 значительно значительно резвее. Плюс как ни странно, меньше проблем с звуком. Т.е. звук не репается так сильно как в 2.2 при дисковых IO.

Я пробовал 2.4.0-test2 (или -test3, непомню) на одном довольно сильно загруженном сервере - оказалось 2.4 гораздо лучше себя ведет при нагрузке и на глаз работает быстрее. На 2.2 правда пришлось всеравно откатиться по причине глюкавости тогдашней версии.

Вообще-то БД на FS не место. Ей на raw-device пылиться надыть, ибо СУБД куда лучше знает, как там что кэшировать, чем ОС. Так шта, не тот критерий, блин.

v test2 byl gluck s ext2, v test3 on uzhe pofixen

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