Производительность разных ФС для /usr/

Вас графики в jpg кто научил сохранять?

OpenOffice3

офф: вижу юзерагента опера и линуксс, это давно так или после треда на лоре где слезно упрашивали администрацию сделать такую фишку?

>офф: вижу юзерагента опера и линуксс, это давно так или после треда на лоре где слезно упрашивали администрацию сделать такую фишку?

Задумано было давно, но та тема была толчком к реализации. О чём в теме, соответственно, и было написано :)

Хм, скорее всего я забыл, ибо тему ту читал.

Где это видно?

Ы. Тэги глючат :)

http://www.linux.org.ru/view-message.jsp?msgid=2830545

Этих тем не видно по соответствующим тэгам.

ЕМНИП там показывается только за последний месяц кажись.

ps. на работе перевел хомяк на xfs и через неделю уже совокупился с ней, в силу неких факторов был удален исходник, переписывать лень... Оказалось что встроенных механизмов восстановления нету, и восстановление представляет собой тупой поиск грепом по винту 8(

>Оказалось что встроенных механизмов восстановления нету

Ну, мне это не особо актуально, у меня всюду либо бэкапы, либо VCS :)

Уж «hg init» в любом каталоге набрать можно :)

Это мой косяк что не юзаю vcs, но начальник использует cvs а она не приветствует ручные манипуляции с файлами.

>Это мой косяк что не юзаю vcs, но начальник использует cvs а она не приветствует ручные манипуляции с файлами.

Просто распределённые VCS (тот же Mercurial) не требуют внешней поддержки. Т.е. входишь в каталог, пишешь «hg init» - всё, локальный репозиторий готов. Идёшь в любой подкаталог, пишешь «hg add <filename.ext>» - файл учитывается в VCS. Потом из любого места «hg ci» - всё, оно коммитится в локальный репозиторий.

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

Хм, нужно поглядеть, как оно будет жить если проект я таскаю домой периодически.

резюме: use ext3

Так вот ты какая, Reiser4..

> их последующих пяти брались

во-во, разница в пределах погрешности

Теги показывают новости только за последний месяц...

— А как за весь период? — да никак, этот чёртов ЛОРРРРЁЁ!!!

Спасибо, исправил.

Я что-то не вкурил - как померить время запуска firefox?

Да, еще одна очепятка:

> время выполнения ld-config.

>во-во, разница в пределах погрешности

Ну, там погрешность явно ниже, чем 50-70% разницы для ext3 и xfs, например :D

>Да, еще одна очепятка:

Fixed.

>Я что-то не вкурил - как померить время запуска firefox?

Я измерял так:

От рута:
# sync && echo 3 > /proc/sys/vm/drop_caches

От юзера:
$ rm ~/.mozilla/firefox/nv80x0ua.default/{parentlock,XPC.mfasl,sessionstore.js}; time firefox & while [[ $(xwininfo -root -tree|grep 'Mozilla Firefox' |wc -l) == 0 ]]; do echo -n . ; done; killall firefox

Мутно. Глаза слезятся (я серьезно).

я наверно слепой, но мне кажется что min|iomin у ext3 и reiser4 отличаются мало, а вот max|iomax явно не в пользу последнего, мне кажется надо считать среднее значение ибо среднее арифметическое - "хорошая оценка" с точки зрения статистики

>я наверно слепой, но мне кажется что min|iomin у ext3 и reiser4 отличаются мало, а вот max|iomax явно не в пользу последнего

+1. Не понятно, чем же лучше рейзер (дада, я ориентируюсь только по самому худшему сценарию)?

вывод как сказали раньше: use ext3

А kron73 случайно не balancer? Тогда ему респект, мне нравились его сборки l2java. ИМХО лучшие в своем роде.

>Мутно. Глаза слезятся (я серьезно).

А точнее? Картинки? Дизайн? :)

>я наверно слепой, но мне кажется что min|iomin у ext3 и reiser4 отличаются мало

Если только в тесте на Amarok :) На тот же ldconfig или SeaMonkey посмотри: 8,4/8,0 против 13,8/13,4 - торможение на 64/68% для ldconfig и 3,4/2,8 против 5,2/4,4 - 53/58%.

>А kron73 случайно не balancer?

Он самый.

>Тогда ему респект, мне нравились его сборки l2java

Ещё есть шансы (не очень высокие, правда), что проект продолжит работу.

>Ещё есть шансы (не очень высокие, правда), что проект продолжит работу.

Несмотря на то, что не Ъ, нужна была реклама проекту. Да еще и перевод клиента и серверных html`ек штатным ЛОРовским анонимусом. Вот тогда ШОК R.I.P

А нравился мне сервер гораздо более четкой работой мобов, квестов и скиллов, да еще и ресурсов жрал меньше. Кстати это нормально что l2j server порет под линуксом без народа 250 Мб памяти, а под вендой 700 Мб?

А где ext4 (который, кстати, уже стабилен)?

>Несмотря на то, что не Ъ, нужна была реклама проекту.

Нужна. Только я рекламой не умею заниматься, а на призыв «требуются [в том числе] активисты-рекламщики» народ как-то не шёл... :)

>А нравился мне сервер гораздо более четкой работой мобов, квестов и скиллов, да еще и ресурсов жрал меньше.

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

>Кстати это нормально что l2j server порет под линуксом без народа 250 Мб памяти, а под вендой 700 Мб?

Фиг знает. У меня он сейчас 580Мб RSS + 1102Мб VIRT жрёт :) Правда, это одна из последних версий, где уже геодата закладывалась, м.б. от неё отжирается.

>А где ext4 (который, кстати, уже стабилен)?

Я писал, почему он не прошёл тестирование :)

Вернее, я про ext4dev писал.

ext4 у меня пока нет. Я не спешу на 2.6.28-е ядро.

>Нужна. Только я рекламой не умею заниматься, а на призыв «требуются [в том числе] активисты-рекламщики» народ как-то не шёл... :)

Десяток ЛОРовских троллей подсунуть к "чужим" и все пучком.

>Фиг знает. У меня он сейчас 580Мб RSS + 1102Мб VIRT жрёт :) Правда, это одна из последних версий, где уже геодата закладывалась, м.б. от неё отжирается.

Только геодате требуется 2 Гб памяти.

Я так кол-во сжираемой памяти мерял:

пускал free -m смотрел расход, допустим 40 Мб, потом пускал сервер, ждал загрузку, расход был 290 Мб. Под вендой смотрел в диспетчере, да и тормозит там гораздо сильней.

Чтож, выходит, что против фактов не попрёшь.. Придётся тебе, таки, использовать эти ненавистные xfs и Reiser4, вместо столь любимой ext3.. ;-)

> От юзера: $ rm ~/.mozilla/firefox/nv80x0ua.default/{parentlock,XPC.mfasl,sessionstore.js}; time firefox & while [[ $(xwininfo -root -tree|grep 'Mozilla Firefox' |wc -l) == 0 ]]; do echo -n . ; done; killall firefox

Неправильное решение! Правильное - загружать html с JS, который закроет браузер или заставит его что-нить написать в /dev/std{out,err}

> офф: вижу юзерагента опера и линуксс, это давно так или после треда на лоре где слезно упрашивали администрацию сделать такую фишку?

Где?? O_o

Реальные пацаны - /, /home - ext3

все файлопомойки - XFS

все надёжные хранилища данных - ext2 (то, что редко меняется)

>Только геодате требуется 2 Гб памяти.

Это в официальном варианте :) Я для тестов у себя на домашнем Целероне с 1Гб запускал Eclipse и в нём в отладчике - YourKit Profiler + L2Fortress с геодатой. Да ещё там, понятно, mysql, apache, торренты всякие в памяти. И ещё кодил в таком режиме :) Но пока разбирался с геодатным маршрутизатором команда окончательно померла :) Точнее, основное ядро свалило в закрытый проект в надежде срубать бабок, а те, кто остались быстро потеряли к проекту интерес или изначально не могли программировать...

>Я так кол-во сжираемой памяти мерял:

Ну, фиг его знает, я сейчас сервер перезапускать не буду. А то у меня там сейчас каким-то чудом откуда-то четыре игрока вдруг сидит :) А то, вроде, совсем помер сервер уже с год как: http://la2.balancer.ru:7776/stat.html (т.е. работает он всё это время позабытый позаброшенный на автопилоте исправно, но народ исчез).

>Чтож, выходит, что против фактов не попрёшь.. Придётся тебе, таки, использовать эти ненавистные xfs и Reiser4, вместо столь любимой ext3.. ;-)

Не... Ты всё перепутал :) К ext3 у меня отношения индифферентные, Reiser4 мне понравился по результатам тестов (кто ж знал такую подлянку с долгим юзанием /usr?) с XFS - да, у меня с ней карма... :D Но я не фанатик, так что /usr уже работает под xfs.

>Неправильное решение!

Но окно отрисоваться успевает :-p

>Где?? O_o

По ссылке «подробнее», в самом низу постинга, у таглайна.

>Но reiser4, как оказалось, не лишён проблемы, с которой началась эта тема.

Думаю, что этого не лишены и другие ФС (особенно ext3 при работе с каталогами)

>Думаю, что этого не лишены и другие ФС

Ну, вот, поглядим теперь, как в /usr себя поведёт xfs :) (на разделах с p2p-закачками сейчас хорошо справляется, хотя там фрагментация до 40% доходит на несколько сот гигабайт).

Благо, скорость /usr проверить сейчас легко, по времени выполнения ldconfig. Эталонные значения для моей системы в таблице зафиксированы. А потом, если что, и xfs defrag можно прогонять будет :)

Стоит заметить, шрифты на диаграмме просто прелестны.

Все претензии к OpenOffice3 :) Понятно, что в MS Office было бы и .png, и шрифты нормальные, но лениво MSO в виртуалке разворачивать...

> По ссылке «подробнее», в самом низу постинга, у таглайна.

ясно, а то я уже подумал, что на ЛОРе...

> в силу неких факторов был удален исходник, переписывать лень... Оказалось что встроенных механизмов восстановления нету

Мало того, что целые колонии анонимусов на это попадались, так еще и регистранты повадились. Вам не говорили, что исходные коды нужно в VCS хранить? И не удалять. Никогда не удалять.

> Ну, вот, поглядим теперь, как в /usr себя поведёт xfs :) (на разделах с p2p-закачками сейчас хорошо справляется, хотя там фрагментация до 40% доходит на несколько сот гигабайт).

Да нормально она (XFS) себя поведёт. Вот с торрентами и правда засада была, когда не хватало скорости чтения скачанного файла, чтобы писалка на полной скорости писала. На /usr таких проблем не будет. Проблемы только с торрентами у меня были -- если клиент преаллокейшен не делает, то файл пишется сильно вразнобой, фрагментируется ужасно. Спасался xfs_fsr /home на ночь.

> Ну, вот, поглядим теперь, как в /usr себя поведёт xfs :) (на разделах с p2p-закачками сейчас хорошо справляется, хотя там фрагментация до 40% доходит на несколько сот гигабайт).

Одумайтесь. Вы, прошу прощения, городите чушь. Если Вы попросили p2p предсоздавать файлы перед закачкой то в 3% фрагментации на xfs Вы должны были уложиться (и то это много). Иначе у Вас то-ли просочился баг или нехватает оперативки для полноценного кеширования.