Я, честно говоря, уже хочу вернуть всё с reiser3'a на ext3, снова вспоминая Why ReiserFS sux: http://linuxmafia.com/faq/Filesystems/reiserfs.html

наконец-то кто-то развенчал миф о суперскорости райзера

Угу. В газетах развенчивают, но вот bonnie++ упрямо коронует обратно. Хотя надо перепроверить, вдруг за последние полгода чтой-то кардинально поменялось.

Эх. Где-то прочитал фразу в которой говорится, что если мол хотите себе шустрый скази винт, то и процессор вам нужен будет шустрый. У меня рейзер4 показывала (свалил с нее т.к. ничем еще не поддерживается) большую скорость чем тот же рейзер3 (атлон 2.2). Может в этом дело?

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

Да, прочитал, хорошо что я уже несколько лет с ext3 никуда не дергаюсь. Вот еще бы утилитку GUI какую сделали бы для resize, move... было бы вообще здорово!

> Вот еще бы утилитку GUI какую сделали бы для resize, move... было бы вообще здорово!

QtParted

А вы сами тестировать не пробовали? Аль за вас все дяди сделают? Наивные... Я сам тестировал ext3, reiserfs, reiser4 и могу сказать, что НА МНОГИХ операциях reiser4 быстрей в РАЗЫ.

а фигли не умеет она даже с ext2, fat32 - пожалуйста. А еще GNU называется - бред!

У них на тестовом компьютере 500mhz

для Raiser4 нужен быстрый CPU

> reiser3 и reiser4 показали самые плохие результаты,

вроде же suse сделали ставку на reiser 3, поэтому их дистрибутивы так тормозят?

А parted может только размер менять и то не всегда. Хотя теоретически с помощью ext2progs давно модно было бы сделать move, в ASPDiskManager было же.

>а фигли не умеет она даже с ext2

он же просто оболочка для утилит типа ext2resize, может он у вас не последней версии или не с теми опциями собран?

А move, MOVE! где?

Недавно менял ext3-раздел. Все работает.

Сам перешел около года назад с reiser на ext3. Пока жаловаться не на что. А вообще, каждую ФС нужно юзать под задачу.

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

Купил намедни второй веник, стал копировать фильмы с первого на второй (из-под рута, без nice +20. просто cp /aaaa /mnt/sdb1/bbbb). Так вот в это время работать в системе было невозможно. Файловая система (на обоих разделах) - xfs, памяти - 1024Mb, CPU - PIV 3Ghz, винты SATA.

>Купил намедни второй веник, стал копировать фильмы с первого на второй (из-под рута, без nice +20. просто cp /aaaa /mnt/sdb1/bbbb). Так вот в это время работать в системе было невозможно. Файловая система (на обоих разделах) - xfs, памяти - 1024Mb, CPU - PIV 3Ghz, винты SATA.

Точно такаяже картина. Вопрос к гуру, от XFS такие грабли?

> Так вот в это время работать в системе было невозможно
io scheduler поменяй.

>Купил намедни второй веник, стал копировать фильмы с первого на второй (из-под рута, без nice +20. просто cp /aaaa /mnt/sdb1/bbbb). Так вот в это время работать в системе было невозможно. Файловая система (на обоих разделах) - xfs, памяти - 1024Mb, CPU - PIV 3Ghz, винты SATA.

# hdparm -d /dev/sda

# hdparm -d /dev/sdb

hdparm не использует фс

Он говорит: DMA включен??!!

интересно где он щас по дефолту не включен? dma

Ну, если копирование видео считать показателем... с sata на ide, оба reiser3, AthlonXP 2500+. 45 Мб/с, загрузка ~10%

>io scheduler поменяй.

А можно по подробней? Или где почитать?

Полгода назад проводил свои измерения reiser4 vs ext3 по скорости запуска приложений. На Reiser4 приложения запускались в среднем в 1,5 раза быстрее. А про то сколько времени ext3 образы dvd удаляет я вообще молчу. Комп athlon 2100 (210x10)/HDD wd1600pb/nforce2

Когда сжатие прикрутят скорость возрастет пропорционально коэффициенту сжатия - в среднем еще в два раза. Нагрузка на проц тоже в разы. Современным файловым системам нужны мощные процы и это правильно, так как пока происходят файловые операции система находится в ожидании данных и проц все ровно не используется. Для десктопа лучше пожертвовать процессорное время на ускорение файловых операций.

А тест в топку - о какой производительности можно говорить на такой тестовой конфигурации? Там же в проц все уперлось!!!

>Так вот в это время работать в системе было невозможно...винты SATA.

я столкнулся с подобным, когда заимел первый комп с сатовским винтом (Athlon64 3200, 512 ram, Seagate 80gb SATA). Правда система там ВинтовсХР была. Так вот, поставил я на новый комп систему, все отлично, все летает... Но, когда с моей тачки кто-нибудь сливал по сети большой файл, все просто умирало. Но с винта на винт скорость отличная и торможения не ощущалось.... 

ЗЫ Только за использование винтовса не ругайте, тогда я еще не знал про линукс, сейчас уже исправился

Очень интересное сравнение, дейсвтительно, получается, что JFS стала оптимальной. А ext3 - для любителей часто удалять... ;-)

Кто может что сказть толковое о jfs, можно её на рабочую станцию, на сервак ставить? Только серьёзного, а не историй, мол, один мальчик установил ту и было ему нещастье, а другой установил ту и было ему щастье... ;-)

> Вопрос к гуру, от XFS такие грабли?

Нет. Сейчас все замечательно копируется и не тормозит. C xfs на xfs

> так как пока происходят файловые операции система находится в ожидании данных и проц все ровно не используется. Для десктопа лучше пожертвовать процессорное время на ускорение файловых операций.

Категорично! О том, что linux (пока) считается системой многозадачной и, особенно на десктопе, могут быть приложения, которые целиком в памяти или получают данные из сети, мы вспоминать не хотим? ;-F)

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

Быстренько идем читать доку к ядру. Уже много лет как это неверно, ибо ядро обладает кучей механизмов асинхронного I/O.

Полный гон! Юзаю XFS уже года 4, если бы не она, много чего потерял, винты сыпяться физически, а я спокойно монтирую, беру и хотя бы часть но копирую, обычно теряешь 2-4 файла, но не все данные. При копировании не замечал тормоза как Вы описываете, всё таки хочу попросить Вас чтобы вы проверили, включены все необходимые параметры для винта (hdparm).

Единственное что тут может быть причиной тормознутости - SATA - она вина, на P-ATA винтах я такое никогда ненаблюдал.

Лично мне нравиться тем XFS что она работает, пусть нам на 5-7% тормознее чего-то, мне важно сохранить данные, а секунда,минуты - я потерплю.!

>Кто может что сказть толковое о jfs, можно её на рабочую станцию, на сервак ставить? Поделие IBM. А эти или сделают полное говно или такая конфетка что любо-дорого. На Linux'e не пользовал, но под OS/2 году в 2000-м она работала весьма и весьма неплохо. Шустро и вполне надежно.

> It actually takes minutes to hours mounting a ReiserFS filesystem on a large RAID

Насколько массив должен быть большим чтобы монтировался минутами??? У меня такой же как на тестовой конфе 400Gb Seagate (только SATA NCQ). Монтирование занимает около 3-4 секунд, камень PIII 850Mhz.

>А можно по подробней? Или где почитать?
в ядре включаешь все
device drivers->block devices->IOShedulers
а потом ядру при загрузке передаешь дефолтный
для лило это будет так
append="elevator=cfq"
смотришь потом append="elevator=следущий"
для раб. станции рекомендую cfq

> reiser3 и reiser4 показали самые плохие результаты, причём

> reiser4 оказалась самой медленной и самой прожорливой до

> ресурсов процессора файловой системой.

Ну наконец-то независимые тесты подтвердили то, в чем я дааавно убедился на практике!!!

>Купил намедни второй веник, стал копировать фильмы с первого на второй (из-под рута, без nice +20. просто cp /aaaa /mnt/sdb1/bbbb). Так вот в это время работать в системе было невозможно. Файловая система (на обоих разделах) - xfs, памяти - 1024Mb, CPU - PIV 3Ghz, винты SATA.

Понимаю, что забавно, но такую же х..ню я наблюдаю на работе, но с ntfs.

Работать невозможно, скорость не очень (у меня дома на гораздо более хреновом оборудовании копируется быстрее), DMA врублено, проц грузится процентов на 10-20.

В чем дело - хз. Но рядом AMD и там все прекрасно. Подозреваю, что проц (а точнее конвейер) нагадил.

Хотя объяснение не очень.

А как кможно проверить какой текущий sheduler? Просто у меня они все включены в ядре(3шт.)

смешно....рейзер..медленный.... а вот попробуйте полазить в /usr/portage в ext3 и в reiser....результат на лицо..... ext3 в топку! P.S. emerge metadata на reiser пулей... что не скажешь о ext3

>Полгода назад проводил свои измерения reiser4 vs ext3 по скорости запуска приложений. На Reiser4 приложения запускались в среднем в 1,5 раза быстрее. А про то сколько времени ext3 образы dvd удаляет я вообще молчу.

В этом плане да, ext3 не рекордсмен. Рекордсмен fat32, но это ее единственное достоинство.

Насчет запуска - хз. По мне так везде все запускается одинаково. ;)

cat /sys/block/hda/queue/scheduler
активный будет в []

> Я, честно говоря, уже хочу вернуть всё с reiser3'a на ext3, снова вспоминая Why ReiserFS sux: http://linuxmafia.com/faq/Filesystems/reiserfs.html

birdie, будь умнее! Тест -- говно. Проблемы неслитых кешей винтов касаются всех, с внедрением write barriers их должно стать меньше, хотя из друх моих винтов в тачке, cache flush поддерживает только один (где линукс). Скорость JFS на массиве из 5 скази винтов меня неприятно разочаровала. В общем, фигня всё, но где же пчёлы?

Нет, мля, PIO-2 на Serial ATA!

>Насколько массив должен быть большим чтобы монтировался минутами??? У меня такой же как на тестовой конфе 400Gb Seagate (только SATA NCQ). Монтирование занимает около 3-4 секунд, камень PIII 850Mhz.

На одной тачке с множеством дисков (все в рейдах) на 2.4.21 монтирование raiserfs занимало минут 5-10.
После перехода на 2.6.10 всё происходит влёт.

>reiser3 и reiser4 показали самые плохие результаты, причём reiser4 оказалась самой медленной и самой прожорливой до ресурсов процессора файловой системой.

Гыгы. Повторяется история n-летней давности. Сравнение fat16, fat32 и ntfs. На машине с 16 мегами оперативки. NTFS - самая прожорливая и тормозная.

Берем памяти 64 и ntfs занимает первое место.

Смешно, господа, смешно.

Тест загрузки проца вообще здорово из пальца высосан. Коню понятно, что если загрузка не 100%, то узкое место - i/o. Файлуха тут вообще никаким боком не стояла.

> смешно....рейзер..медленный

Понимаю, тяжело бороться с тем, что многие года вдалбливали в голову, что рейзер быстрый... Как попугаи повторяли одно и то же. Кто-то не очень умный ляпнул, что рейзер быстрый, и пошло... Но что поделаешь - с цифрами не поспоришь. Наконец-то это пособие для создания себе геммороя с потерей данных ещё и медленным будет слыть.

> а вот попробуйте полазить в /usr/portage в ext3 и в

> reiser....результат на лицо

Не знаю, что там у тебя с лицом, но это говорит только об одном - гент00 - рвотный порошок :) Поставь нормальный дистрибутив, там всё впорядке с ext3.

> cмешно....рейзер..медленный.... а вот попробуйте полазить в /usr/portage в ext3 и в reiser....результат на лицо..... ext3 в топку! P.S. emerge metadata на reiser пулей... что не скажешь о ext3

А ты в курсе существования коллизий хеша на reiser? Так вот попытается однажды система открыть /etc/shadow,
а там порнуха из /usr/portage/distfiles. )))

Choose which hash function reiserfs will use to find files within directories.

rupasov
A hash invented by Yury Yu. Rupasov. It is fast and preserves locality, mapping lexi-
cographically close file names to close hash values. This option should not be used,
as it causes a high probability of hash collisions.

tea A Davis-Meyer function implemented by Jeremy Fitzhardinge. It uses hash permuting
bits in the name. It gets high randomness and, therefore, low probability of hash
collisions at some CPU cost. This may be used if EHASHCOLLISION errors are experi-
enced with the r5 hash.

r5 A modified version of the rupasov hash. It is used by default and is the best choice
unless the file system has huge directories and unusual file-name patterns.

detect Instructs mount to detect which hash function is in use by examining the file system
being mounted, and to write this information into the reiserfs superblock. This is
only useful on the first mount of an old format file system.

ЗЫ
emerge metadata после sync тормозит дико на reiser3.

> Online издание Linux Gazette во второй раз проводит тестирование

Тогда авторитет Linux Gazette падает в моих глазах "ниже плинтуса", ибо мой личный опыт позволяет утверждать, что jfs -- "так себе", а <a href=http://www.livejournal.com/users/poige/132611.html>Reiser4 -- "круть!"</a>, по кр. мере, по оптимальности хранения данных, и скорости их обработки.

> Online издание Linux Gazette во второй раз проводит тестирование

Тогда авторитет Linux Gazette падает в моих глазах "ниже плинтуса", ибо мой личный опыт позволяет утверждать, что jfs -- "так себе", а Reiser4 -- "круть!", по кр. мере, по оптимальности хранения данных, и скорости их обработки: http://www.livejournal.com/users/poige/132611.html

(извините за повтор, на LOR'е, оказывается до сих пор толком ссылку дать нельзя).

А вот этим не только посмотреть можно, но и поменять, не перезагружая ядро http://vivid.dat.pl/fallow/pub/scheduler_change_script.

Что мне не нравится в ext2 (не знаю как в ext3), так это непредсказуемость после перезагрузки - случайной или специальной. Оно может захотеть прогнать fsck по диску, при этом на что-нить напороться и ожидать команды админа. А админ за 10.000 км ждет с ssh в руках, когда сервер пробудится...

Или что-то изменилось за последнее время? Предлагать менять руками скрипты загрузки и тестить их - не стоит. Бо тестить-то придется на таком же удаленном сервере...

XFS, reiser удобно. Загрузилось, смонтировало, пошло работать. XFS так и вообще лечится на ходу...