>Глупысти.

а ты поищи в тырнете про xp sp2, как это было когда он только вышел. сейчас может и нормально все.

> на двухголовом серваке с Opteron и интегрированным Silicon Image SiI 3114 под CentOS4 наблюдается такой косяк: при копировании больших файлов (больше 500мег) система затыкается

Это известно: bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132697#c6

Кажется, в 2.6.11 из FC4 исправили, во всяком случае я не смог добиться зависания.

Да и тогда особых проблем не было. И микрософт и софтоклепатели сработали оперативно и сейчас от этой "проблемы" остались только статьи в архивах новостных лент.

-> Kernel module load error: insmod: error inserting './usr/src/nv/nvidia.ko':
   -1 No such device
-> Kernel messages:
   NVRM: No NVIDIA graphics adapter probed!
   NVRM: The NVIDIA probe routine was not called for 1 device(s)

фреймбуфер нвышный вкрутил?

>и тогда особых проблем не было.

да что ты говоришь? смотри сюда http://support.microsoft.com/?id=884130

>сейчас от этой "проблемы" остались только статьи в архивах новостных лент.

угу, а микрософт-то не знает. пойду повешу багу на KB884130 :)

> И микрософт и софтоклепатели сработали оперативно

Ну так и мы оперативно сработаем, в чём проблема-то?

просто у батарейкина кончилось электричество 8))

Тьфу... Даже комментировать не хочется. Уже давным-давно повыходили обновления, а ты все еще помнишь. Ладно, обсуждайте тут ядро, а я пошел спать.

>Даже комментировать не хочется. Уже давным-давно повыходили обновления, а ты все еще помнишь

дык не я помню, а МС. а насчет давно повыходили обновления - с этого места поподробнее. если вдруг сейчас в ядре что-то сломали, через три дня повыходят обновления. ну так и не кричи "линукс маздай", сиди жди апдейта к патчу на сервиспак :) ?

> Глупысти.

Energizer, вот тебе парочка интересных примерчиков со знаменитого ресурса, ознакомься:

http://winfaq.com.ru/ubb/Forum15/HTML/011624.html

http://winfaq.com.ru/ubb/Forum15/HTML/011689.html

http://winfaq.com.ru/ubb/Forum15/HTML/011723.html

http://winfaq.com.ru/ubb/Forum15/HTML/011801.html

http://winfaq.com.ru/ubb/Forum15/HTML/011918.html

http://winfaq.com.ru/ubb/Forum15/HTML/012012.html

>Energizer, вот тебе парочка интересных примерчиков со знаменитого ресурса, ознакомься:

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

даже /. опередили

>8| Ты имел в виду, сделать симлинк /usr/src/linux, который указует на /usr/src/linux-2.6.12 ? А что, кто-то этого НЕ делает?

я ядро тока у себя в хомяке собираю

> я ядро тока у себя в хомяке собираю

me too. :)

А ты сам то, собственно, кто тут такой?..

>>Energizer, вот тебе парочка интересных примерчиков со знаменитого ресурса, ознакомься:

Еще один... А посвежее ничего нету?

Я использую дома на десктопе. Проблем нет. Работает стабильно. Правда и задач особых нет, но жаловаться не на что. Ядро 2.6.11.8 патчил сам, скачав пачи с namesys.

ну а как же тестирование и обкатка новой версии компилятора? Разве не преимущество?

> Ок. В ядре переименовали какую-нибудь константу/убрали функцию, дублирующую функционал другой. Ваш драйвер nvidia не собирается. Ваши действия? Лично я просто иду в /usr/src/nvkernel и правлю код, после чего драйвер собирается и заводится. Вы ждете "ебилда", "нового драйвера", "патрика-бога" либо еще чего-нибудь :-)

я тоже так делаю. но рядом находятся 15 человек которые в коде ничего е смыслят. и для них это не прокатит.

Интересно пофиксили ли в 2.6.12 эту багу, а то сегодня с 2.6.11-r4 встал на грабли:

Jun 19 08:19:26 censored kernel: attempt to access beyond end of device
Jun 19 08:19:26 censored kernel: hdc: rw=0, want=67108332, limit=4
Jun 19 08:19:26 censored kernel: isofs_fill_super: bread failed, dev=hdc, iso_blknum=16777082, block=16777082
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
Jun 19 08:19:26 censored kernel: device blocksize: 2048
Jun 19 08:19:26 censored kernel: __find_get_block_slow() failed. block=18446744073709551482, b_blocknr=4294967162
Jun 19 08:19:26 censored kernel: b_state=0x00000010, b_size=2048
...

>Еще один... А посвежее ничего нету?

посвежее? да такие косяки постоянно вылезают. А причина у этого одна - любой win32-софт (и драйвера, кстати, тоже) разрабатывается для сферического компутера в вакууме. Т.е. девелоперы априори предполагают, что кроме их гениальной программы ничего на компе не стоит. Вот скажи мне, зачем автокад при установке переписывает библиотеки M$ офеза? =) А уж история, как пейсатели драйвера мышки полгода (или год) искали причину, почему их гениальный драйвер роняет XPень в BSOD....no comments, короче =)

>> Вот скажи мне, зачем автокад при установке переписывает библиотеки M$ офеза? =)

ХЗ. И что потом происходит?

>> А уж история, как пейсатели драйвера мышки полгода (или год) искали причину, почему их гениальный драйвер роняет XPень в BSOD....no comments, короче =)

Перечитай этот тред, открой для себя мир глюков в линуксе.

ps: И вообще я рад, что моя мысль http://www.linux.org.ru/view-message.jsp?msgid=958036#958758 наша среди линуксоидов молчаливое одобрение ;).

"наша" читать как "нашла"

2 JB и 2 db у меня был вариант когда мог сравнить reiser4, reiserfs, i ext3. Просто скопировал откомпилированое дерево исходников ядра с одного reiserfs раздела на одном диске на reiserfs раздел на другом диске, проделал аналогичные операции во всех сочетаниях : reiser4 -> reiser4 reiser4 -> reiserfs reiserfs -> reiserfs reiser4 -> ext3 reiserfs -> ext3 разница в скорости копирования между reiser4 и reiserfs до двух раз в среднем, o ext3 лучше не говорить. Когда скопировал 500Мбт файл с раздела reiser4 одного диска -> на reiser4 раздел другого диска я получил скорость копирования около: 50Мбт/сек Копирование этого файла завершилась за 10 секунд !!!!!!!!! Это порядка 95% от физической возможности диска. Кто нибудь может мне сказать про ОС и фс, на которых можно достигать сравнимых скоростей? Недавно, я скриптом создал дерево из 16 поддиректорий в каждой из которых было до 20000 1кбт файлов. Итого 320 000 файлов. find на разделе reiser4 прошел все за 10 секунд, такое же дерево на reiserfs за 30 секунд.

>ХЗ. И что потом происходит?

глюки потом происходят. или не происходят (зависит от фазы луны).

>Перечитай этот тред, открой для себя мир глюков в линуксе.

вот "плавающих" глюков в линуксе нету. Или работает или нет =) а оффтопик обладает потрясающей способностью быть чуть-чуть беременным.

>>глюки потом происходят. или не происходят (зависит от фазы луны).

Т.е. наверняка ты не знаешь, кто виноват в глюках... Я спрашивал, потому что ставил и МСО и АвтоКАД, но никаких глюков не наблюдал.

ps: Ладно, завязываем. Хочешь чего мне сказать - иди в толксы.

>Т.е. наверняка ты не знаешь, кто виноват в глюках..

совершенно верно. Не знаю. потому как мне в лом дизассемблировать венду, офез и автокад =)

> Еще один... А посвежее ничего нету?

Ты слабоумен? А сервиспака у тебя посвежее нету? Как вышел sp2 - так и попёпли траблы. А ты хотел, чтоб они появились через год после его выхода, что ли?

И с линуксом у меня, что характерно, тоже примеров нету. Вот собрал 2.6.12, загрузился - и всё работает, никаких траблов, никаких ошибок в логах... Кривые у меня руки, что с меня взять...

> фреймбуфер нвышный вкрутил?

да

А что это nvidiafb не работает ни модулем, ни в ядре? Загружается и нечего не происходит. У меня GeForce 6600.

У кого-нибудь иначе?

A.K.

скорость FS

2 arjin
> сравнить reiser4, reiserfs, i ext3. Просто скопировал ...
Уважаемый, такие замеры надо гораздо аккуратнее проводить, чем делаете вы.

1) Очищали ли вы все возможные кэши(винчестера, ядра) после каждого замера ? Это я о том что надо перегружатся прямо _перед_ каждым замером!

2) Винчестер может с различной скоростью считывать сектора в начале и а конце винта. То есть надо каждую файловую систему создавать на одном и том же месте(разделе).

3) Интересны также скорости удаления и чтения файлов. (перегружатся перед каждым замером)
можно написать скрипт который будет это все делат ( создавать fs на /dev/hda1, перегружатся, копировать , запис время копирования, перегружаться , считывать , перегружаться , удалять , создавать след fs, ... )

4) надеюсь XFree у вас на время измерений не было запущено и сетевым интерфейсам не забудете down сделать ???!!!

Ты не понял. Райзер только напряжённой работой с кешем и берёт (и при этом огого как проц грузит, кстати: в топку такое на ноутбуках). В остальном он ничуть не лучше той же ext3. Если его лишить кеша - будет то же, что и у остальных. А ты как раз и предлагаешь это сделать путём перезагрузки.

> find на разделе reiser4 прошел все за 10 секунд

Я тоже делал подобные тесты, только на С. Цифры не помню, но соотношение сил то же. ReiserFS всегда позиционировалась как ФС для работы с большим количеством файлов, когда происходит общение не столько с самими файлами, сколько с ФС. Поэтому возникает мысль провести такой тест: программа создаёт несколько больших файлов и теребит их всякими seek, read, write, sync. ReiserFS 3.6 в общем медленнее, чем Ext3. Reiser4 не пробовал. Кому не лень, сделайте и покажите.

>> фреймбуфер нвышный вкрутил?

> да

Пересобрал без него и дрова встали.. И зачем тогда этот nvidiafb??

Могу сказать о следующее, было около 3-4 одинаковых дисков,
разбитых по одной схеме,и копирование в основном делалось
приблизительно в тех же секторах
hda3->hdb3
hdc3->hde3
Влияние места на диске конечно есть, но все были в одинаковых условиях.

Результаты повторялись по нескольку раз, я делал копирование в разной
и случайной последовательности, и абсолютное время не сильно отличалось (я делал многое без перезагрузки ).
Для больших файлов 500мбт, размер
которых сравним с размером ОЗУ, кеширование не могло играть заметной роли, и потому для этих файлов времена копирования были почти
постоянны - была налицо хорошая повторяемость.
Я не ставил целью делать образцовый тест, но того что я сделал было
вполне достаточно, что бы заметить и зафиксировать существеную (мягко
говоря )разницу скоростей reiser4, reiserfs.
Я хотел проверить утверждение о том, что reiser4 не имеет проблем
работы с большими файлами , характерных для reiserfs .
P.S
А если вы мне скажете как очищать кеши винчестера и ядра, и как мог
повлиять пункт 4 - будет просто прекрасно :-)

Ощутимо выросла скорость работы приложений по сравнению с 2.6.11!

> Ощутимо выросла скорость работы приложений по сравнению с 2.6.11!

Это ты как определил?

> Ты не понял. Райзер только напряжённой работой с кешем и берёт (и при этом огого как проц грузит, кстати: в топку такое на ноутбуках). В остальном он ничуть не лучше той же ext3. Если его лишить кеша - будет то же, что и у остальных. А ты как раз и предлагаешь это сделать путём перезагрузки.

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

> > Ощутимо выросла скорость работы приложений по сравнению с 2.6.11!

> Это ты как определил?

Написано же, ощутил:)

> Написано же, ощутил:)

Может, голоса? :) В этом случае делается простой тест - в lilo заносится два пункта - linux_2.6.11 и linux_2.6.12. После этого просим кого-то из домашних загрузить произвольное ядро (не говоря, какое), работаем с ним (перделки типа gkrellm, демонстрирующие у большинства кульхацкеров версию ядра для пущего запугивания своей дэвушки, д.б. отключены) и пытаемся угадать, что это было. Сюрпризы гарантирую. Для уверенности повторить по 5 раз с каждым из ядер в произвольном порядке.

Кстати, а никто не заметил, что в новом ядре поменялись некоторые прототипы низкоуровненых функций, поменялись структуры? В частности, поменялся прототип функции sk_alloc? Изменилась struct sock. KLIPS для openswan-2.3.1 нормально не собрался...

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

Лично я был вынужден откатится на 2.6.11.12. Там с этим все ОК. 8-(

блин под vmware и 4 и 5 перестал работать модуль ихний для сетки
при подключении вылетает с какимто debug трэйсом...
после этого не вские ifconfig и тд не запускаются, просто какбы подвисают... пришлось обратно на 11

Если идет работа с большими файлами большими потоками - XFS рулит, честно-честно, сам проверял. EXT2/EXT3 отстают, но показывают достаточно стабильные результаты, а вот Reiser (правда версии 3, а не 4) при увеличении количества читающих/пишущих начинает "проседать" гораздо резче.

Был еще один случай: знакомые держали на файловом сервере под самбой reiserfs. После того, как начались затыки с производительностью, перекатились на XFS - действительно, с производительностью стало несколько лучше.

> блин под vmware и 4 и 5 перестал работать модуль ихний для сетки

Опа! Тебе показать скрин на ядре 2.6.12 с vmware 4.5.1 и с работающей vmware'вской сетью? :-)

> после этого не вские ifconfig и тд не запускаются, просто какбы подвисают... пришлось обратно на 11

Эт ты зря... Там работы на 5 минут - только не лениться и шаг за шагом пройти всю конфигурацию.

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

Как сделал я: поставил VMWare, пропатчил модули (4.5.1 не соберется на этом ядре, другой под рукой не было).

Запустил конфигуратор - он собрал модули, но повис - т.е. факт имеет место быть! :-)

Перезагрузился, сказал /etc/init.d/vmware stop

Положил бинарники модулей в /usr/lib/vmware/modules/binary/up-2.6.12-FC3/objects, подправил /usr/lib/vmware/modules/binary/up-2.6.12-FC3/properties.

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

ok спасиб попробую...
зы тоже FC3

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