Вин7 красивая.

>Так что выкидывайте нафиг свои флэшки, проблема в них а не в ядре, слишком умные они (флэшки) стали со своими контроллерами.

теперь попробуй на системе, которая любит на флешки autorun.inf записывать. ты удивишься.

Вообще-то на флешки надо писать используя файловый менеджер который при копировании заранее выделяет место для нового файла. А при использовании команды «dd» этого не происходит. Отсюда и тормоза на флешке. Как раз виндовский Проводник выделяет сразу место.

> теперь попробуй на системе, которая любит на флешки autorun.inf записывать.

Пробовал. Скорость та же самая.

> А при использовании команды «dd» этого не происходит.

Слышь, школьник, dd of=/dev/sda1 вообще пишет не файл на файловую систему, а напрямую на устройство блок-в-блок.

Видишь ли, деточка, эффективная скорость записи В ПРИНЦИПЕ не может быть выше физической скорости записи (3.8), поскольку эффективная = физическая - накладные_расходы. Я понимаю, что тебе очень не хочется в это верить - также как многим не хочется верить в то, что скорость выполнения helloworld не зависит от опций компилятора... Но, к вящему для тебя сожалению, это факт. И HDD, на который файлы копируются с нормальной для USB скоростью, это только подтверждает. Вот такой вот он, этот жестокий мир, который со страшной силой бьет идиотов по лбу фактами

много пафоса и мало фактов, деточка. про скорость записи В ПРИНЦИПЕ ты тоже явно не в курсе.

> много пафоса и мало фактов

От тебя вообще ни одного факта не было. Сливаешься, толстенький и зелененький :-)

> Вин7 красивая...

Теплая, ламповая..)

>Это возможно примерно настолько же, насколько возможно вообще не иметь багов. Я заинтересовался, почитал что это за баг. Это просто куча разрозненных репортов, часто не связанных, у которых общее только iowait. Т.е. разработчику в этом топике даже нет смысла тусоваться, пока он будет фиксить одну проблему, остальной народ будет кричать «а мне не помогло». Там смешано в кучу и криптование, и dm/md/lvm, и проблемы с журналом ext3, и проблемы с большими файлами на ext4, и cfq, и cfs, и запись на SSD, работа с USB... — разбираться с проблемами надо по одной за раз, и чтобы левые репорты не мешались, но это не этот случай. Так что 12309 можно смело игнорировать.

u menja dazhe pri sudo urpmi blackbox sistema vstaet namertvo na 15 sekund. pri tom, 4to nikakix lvm i pso4ix net. Rabotat nevozmozhno normalno uzhe god. Xo4u na 2.6.16 otkatitsa

[root@viking-ws ~]# dd if=/dev/sdc1 of=/home/cache bs=1024k count=100 
100+0 records in 
100+0 records out 
104857600 bytes (105 MB) copied, 9,37432 s, 11,2 MB/s 
[root@viking-ws ~]# dd of=/dev/sdc1 if=/home/cache bs=4096 
25600+0 records in 
25600+0 records out 
104857600 bytes (105 MB) copied, 27,5365 s, 3,8 MB/s

А почему такой маленький размер блока при записи? По идее флешки должны быстрее записывать если размер блока 16КБ, 128КБ, 256КБ или 512КБ. Флешки под рукой нет, так что проверить не могу.

>эффективная скорость записи В ПРИНЦИПЕ не может быть выше физической скорости записи

И тут в рельность врывается буферизация и путает тебе все карты.

также как многим не хочется верить в то, что скорость выполнения helloworld не зависит от опций компилятора

Зависит. Например, если собрать статически - сэкономятся до сотни мс на одном только seek time для россыпи гнутых либ.

> sistema vstaet namertvo na 15 sekund

Транслит — сакс. Проблему надо искать, идентифицировать. Если появилась при смене ядра, есть git bisect. Разработчиков надо информировать. Но не так, как в баге «12309», когда собственно нужные люди в этой каше даже копаться не станут.

> Например, если собрать статически - сэкономятся до сотни мс на одном только seek time для россыпи гнутых либ.

Они уже в кеше, как правило.

Так сделали уже, b43 поддерживает. У меня на 33 ядре работает. Правда пришлось его пересобрать c CONFIG_B43_FORCE_PIO=y.

> И тут в рельность врывается буферизация и путает тебе все карты.

Наивное существо, советую запомнит буферизация важна когда существует «дорогой seek».

Специально сейчас развлекался - копировал 700 мегабайт на гигабайтную флэшку в линуксе (date; cp; umount; date) и в винде - в FARе и средствами эксплорера. В винде время 2:10 .. 2:22, в зависимости от «фазы луны» (четыре повтора, все времена примерно в равном диапазоне, а в линуксе от 2:10 (обычный dd,fdatasync+deadline), 2:16 (dd,fsync+deadline), 2:26 (cp+noop) и вплоть до 2:22 (cp+deadline).

Я в упор не вижу разницы, которая бы была за пределами погрешности измерения :-)

> сэкономятся до сотни мс на одном только seek time для россыпи гнутых либ.

Школьники тааакие школьники... Повторное открытие уже открытой библиотеки в линуксе стоит ноль целых хрен десятых дисковых операций :-)

> ага, это при том, что swap отключен ;D

А вот и кандидат на причину. Оптимизаторы, етить вас налево. С вашими кривыми шаловливыми ручонками ни один баг не найдешь, потому что он в ДНК!

prelink, не?

>> да что тут мои рассказы? )) когда даже Гугл выбрал именно линэкс. причем, им >скорость/стабильность очень нужна - не зря они так долго использовали ядро 2.4 и ext2.

Угу.. Чуваки из Оракла тока вот не знали, когда за Sun 5+ ярдов отваливали. Могли бы сэкономить, ведь у них уже есть линакс :-)

они ярды отваливали за java + железо. Плюс возможность рулить развитием java и javaEE. Solaris пошел довеском. Потому у них сейчас 2 свои ОС + еще куча поддерживаемых.

> что с багом 12309 ?

Это тот самый невоспроизводимый баг, который вызывает почти полный вис всей системы, например, при копировании на флешку? Если да, то недавно на единственной машине (с дебианом), на которой он мне встретился, его удалось решить так:

http://welinux.ru/post/2222/

Если у кого это воспроизводится - проверьте, работает ли у вас.

>> что с багом 12309 ?

http://welinux.ru/post/2222/

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

for i in /proc/irq/*/smp_affinity; do echo 1 > $i; done

Это - далеко не оптимальное решение, но для теста - сойдет.

> Когда уже уберут дублирование логотипов пингвина при загрузке, а то уже копировал fbmem.c раз 5, и патч не принимают. Жду 2.6.34.4 тогда посмотрю.

Количество логотипов равно количеству ядер. И, походу, мне - нравится. :) Я против того, чтобы его убирали. Всегда мечтал увидеть его на 32-ядерной машине.

Ох, вот если бы его на 1024-процессорном посмотреть...

А что, 12309 «работает» только smp-системах?

> они ярды отваливали за java + железо. Плюс возможность рулить развитием java и javaEE. Solaris пошел довеском. Потому у них сейчас 2 свои ОС + еще куча поддерживаемых.

Ларри Эллисон в треде!

> Ох, вот если бы его на 1024-процессорном посмотреть...

Думаешь, от большого количества пингвин как-то качественно изменится?

> А что, 12309 «работает» только smp-системах?

Это - вопрос тем, кто знает, как ее воспроизвести. На ядерной багзилле такой вариант никто не проверял, вроде. Если указанное мной «решение» сработает, то получится, что да.

/me с нетерпением ждет сообщений тех, кто может у себя воспроизвести такую проблему

BFS

http://ck.kolivas.org/patches/bfs/2.6.34-sched-bfs-318.patch

также обновлен патч для .33 ядер
http://ck.kolivas.org/patches/bfs/2.6.33-sched-bfs-318.patch

Сам читай! Или ты только на заборах умеешь писать?