Так у тебя есть проблема или нет?

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

Я сейчас пытаюсь понять, каким тестом из богатой истории этого бага воспользоваться.

Некоторые идеи прозвучавшие в самом начале:

1. отделить народ, у которого проблема фиксится сменой шедулера I/O c cfq на as.

2. Отделить проблемы с шифрованными разделами.

3. Отделить народ с USB винтами и флэхами.

4. SCSI и прочих железных рэйдов на лоре кажется нет.

Т.е. разбить баг на кучу суб-багов по подсистемам.

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

Это очень хорошо, может быть от ЛОР в кои то веки будет толк.

ST9160314AS. В Debian 2.6.32 проблемы нет, в Ubuntu 2.6.32 больше похоже на то, что есть, но непонятно, с чем именно связанная.

>4. SCSI и прочих железных рэйдов на лоре кажется нет.

Как это?

Нетбук LenovoS10
Не сталкивался с этим багом с выхода примерно 2.6.31 или около того.

Дайте точную хауту, как воспроизводить.

ST380815AS(ext3 ordered, relatime)+(ST31000528AS+WDC WD7500AADS-0)(LVM, ext4)
82801GB/GR/GH (ICH7 Family) SATA IDE Controller
Процессор Intel Celeron E1400 (2.0*2)
Памяти 1+1Gb DDR2 PC6400 dualchannel
Таймер дефолтный, проблем с прерываниями нет, кругом CFQ
Ядро 2.6.31.13-desktop-1mnb мандривовское

Баг отсутствует

ноут dell inspiron 1525 (T2370, 1Gb, hdd toshiba mk1246gsx 120gb)
opensuse 11.2 x86 (настройки «по умолчанию»)
тест dd показал возврат во времена форматирования дискет: десктопы на кде4 переключаются с заметной задержкой, вкладки konsole «тормозят» при создании/закрытии

я пробовал «dd if=/dev/zero of=/tmp/test bs=1M count=1M»
более другой тест также хотел бы попробовать

>ноут dell inspiron 1525 (T2370, 1Gb, hdd toshiba mk1246gsx 120gb)

opensuse 11.2 x86 (настройки «по умолчанию»)

тест dd показал возврат во времена форматирования дискет:

Откуда FDD на этой модели ноута? 0_о

У тебя /tmp не в tmpfs?

нет

Попробуем

Доберусь домой, проверю, но, кажется, не сталкивался с таким багом. Дайте по-больше примеров воспроизведения бага.

Пока читаю, там есть несколько зачекнутых (старых?) тестов, для себя сделал пометки такого плана:

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c169 - искусственное вызывние бага

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c183 - libata медленее (?).

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c198 - баг в ICH8M режиме совместимости.

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c215 - куча проблем с интерактивностью навалено в один баг.

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c259 - ставить для старых (28-29) ядер /proc/sys/vm/dirty_background_ratio to 1 and /proc/sys/vm/dirty_ratio to 2. ?

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c268 - НЕ ставить vm.swappines в 1-2!

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c275 - быстрый диск уменьшает вероятность проявления бага.

https://bugzilla.kernel.org/attachment.cgi?id=21007

Пасиба, попробую вечерком

У меня баг починился в районе .32, когда CFQ пилили. До этого даже find на cfq ставил систему раком.

У кого появялется этот баг и полно свободного времени могу предложить скачать ядро из git-а, и попробовать найти, в каком коммите баг появился бинарным поиском

А ещё год назад было сказано .......
https://bugzilla.kernel.org/show_bug.cgi?id=12309#c299
-----------
For anyone who wants to test, here's what to do:
Тестерам, попробуйте сделать так:

1. Document latencies with current setup which is performing poorly.
1. Запишите задержки при обычном проявлении бага в вашей конфигурации


2. Document latencies with 2.6.30-rc1 (which should be much better for most people - make sure that if you are using ext3, that you mount your filesystem with the same journalling mode, as the default has changed)
2. Запишите задержки для случая с новым ядром, не забудьте выставить одинаковый режим журналирования для ext3 при монтировании ЯВНО, дефаулт изменился в 2.6.30!


To document latencies, start a large streaming write:

# dd if=/dev/zero of=/tmp/bigfile bs=1M count=5000

And run Ted Tso's latency testing tool in parallel (grab/compile it from here:
http://lkml.org/lkml/2009/3/24/227)

Для записи задержек запустите процесс dd с указанными параметрами и параллельно запустите программу, которую выложил Тэд по ссылке на LKML.

If you still have questions, read the last 50 or so comments to this bug for more information.

Перечитайте последние 50 комментариев, если вам что-то не ясно (выше от 299-го)

Вспомнил

Такая бага у меня проскакивала на карренте(13) слаки. ядро изкаропки. Правда у меня был ад из винтов в машинке, там было 2 иде и 2 сатовых винта, + идешный двдрекордер. Система периодически уходила в перекуры при стягивании толстых торрентов. ext4, да. Чичас у меня agilia-rc2 с 33 кернелем и террабайтный сатовый винт, чей - не помню. В повседневной работе перекуров не замечено. Дома попробую тесты.

Одинаковый режим журналирования - это как? с чем одинаковый?

Результаты на 2.6.33-gentoo
[code]dd if=/dev/zero of=/tmp/bigfile bs=1M count=5000
5000+0 записей считано
5000+0 записей написано
скопировано 5242880000 байт (5,2 GB), 99,2284 c, 52,8 MB/c
[/code]

[code]
fsync time: 4.1773
fsync time: 1.4996
fsync time: 1.6401
fsync time: 1.8001
fsync time: 1.6749
fsync time: 0.7106
~skipped~
fsync time: 1.6435
fsync time: 2.4646
fsync time: 1.6716
fsync time: 2.8511
fsync time: 1.3439
fsync time: 2.0012
fsync time: 2.8082
fsync time: 0.6662
[/code]
Это под нагрузкой.

когда 5 гиг закончили копироваться на хард такая ситуация:
[code]
fsync time: 0.0994
fsync time: 0.0984
fsync time: 0.0990
fsync time: 0.0991
fsync time: 0.1007
fsync time: 0.0979
fsync time: 0.0988
fsync time: 0.0987
fsync time: 0.0987
fsync time: 0.0981
fsync time: 0.0989
[/code]
Конфигурация машины:
http://paste.pocoo.org/show/214814/
Конфиг ядра:
http://paste.pocoo.org/show/214815/

2г памяти, атом n270

В процессе теста спокойно продолжал пользоваться FF, никаких изменений не заметил.

надо ли тестить на другом ведре?

Так на 34 же

Опс, этот тест уже включили в незачеркнутый вариант авто-тестера.

Также, всплыла отдельная проблема с неработавшим (?) drop_caches https://bugzilla.kernel.org/show_bug.cgi?id=12309#c344

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

Проблемы с fsync на ext3/4 - тоже в отдельный топик.

writeback или ordered. Юмористы запихали в дефолтный конфиг writeback, а мне мои данные важнее (УПС не спасёт от жесткого зависания при тестах со слегка глючной видеокартой).

Но это просто ремарка. Реально довольно сложно прочитать 350+ комментариев и выделить из них суть.

Ну это понятно.
Появится в портэджах - протестирую)

Кажется баг поменял прописку и номер:

https://bugzilla.kernel.org/show_bug.cgi?id=13347 Bug 13347 - Large I/O operations result in slow performance and high iowait times

Ещё 300 комментов :/ (шутка, всего 60)

У меня есть баг на ядре 2.6.32 (Debian Squeeze). Конфиг

• Athlon64 3200+
• 512 DDR
• ASUS A8N-E (nForce 4 Ultra)
• WD2500KS

fsync 2-16 сек.

2.6.34-rc6, баг есть, но теперь уже меньше (такое впечатлнение, что в BFS было хуже с отзывчивостью).

Тестил: while true; do dd if=/dev/zero of=~/test bs=1M count=1M && rm ~/test; done

(т.е. до заполнения винта до отказа и потом снова)

Тормоза есть время от времени (впечатление, что ядро делает в один момент flush и только тогда локальное подвисание).

Забыл: C2D E8600, 2GB RAM, два каких-то WD в fakeRAID0.

Ну и noop IO scheduler

kernel-2.6.33.4-1 Archlinux баг есть, возникает на восстановлении поврежденного файла с помощью par2cmdline. Все виснет на несколько минут, потом отвисает на минуту, потом опять виснет. Файлов в сумме на 38 гигов. Причем на чтении файла (проверка целостности) ошибка не проявляется, только на одновременном чтении и записи. Раньше в gentoo тоже были проблемы, думал что так и должно быть, а сегодня узнал про 12309

А как потестить есть ли этот баг или нет? Есть скрипт какой нибудь? Если запустить dd if=/dev/zero of=~/file bs=1000000, что должно быть?

Сделай dd if=/dev/zero of=~/test bs=1M count=1M и попробуй поработать. Если диск будет переполняться, засунь в цикл, как я.

сделал. firefox немного подвисает, и переключение раб.столов притормаживает. но ничего не зависло и не упало, в принципе, терпимо.

arch, 2.6.34, ext4, AMD SB600, ноутбучный винт

У меня так же. Только в плазме выезжающие панели - очень долго ждать, пока выедут. А так еще неплохо.

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

top:

Cpu0  :  2.6%us,  2.3%sy,  0.0%ni,  0.0%id, 94.4%wa,  0.3%hi,  0.3%si,  0.0%st
Cpu1  :  1.0%us,  0.7%sy,  0.0%ni, 38.2%id, 59.8%wa,  0.0%hi,  0.3%si,  0.0%st

dd:

zkerneltest@localhost:/home/torrents/test$ while true; do dd if=/dev/zero of=~/test bs=1M count=1M && rm ~/test; done
dd: запись «/home/zkerneltest/test»: На устройстве кончилось место
8889+0 записей считано
8888+0 записей написано
 скопировано 9320620032 байта (9,3 GB), 294,309 c, 31,7 MB/c
dd: запись «/home/zkerneltest/test»: На устройстве кончилось место
8889+0 записей считано
8888+0 записей написано
 скопировано 9320669184 байта (9,3 GB), 329,477 c, 28,3 MB/c
dd: запись «/home/zkerneltest/test»: На устройстве кончилось место
8889+0 записей считано
8888+0 записей написано
 скопировано 9320665088 байт (9,3 GB), 296,303 c, 31,5 MB/c
dd: запись «/home/zkerneltest/test»: На устройстве кончилось место
8889+0 записей считано
8888+0 записей написано
 скопировано 9320480768 байт (9,3 GB), 329,164 c, 28,3 MB/c

Раз опера тормозит - знач да. Какая система/конфигурация?

при этом реальная скорость диска:

wieker@localhost:~/Projects$ sudo hdparm -t /dev/sdb

/dev/sdb:
 Timing buffered disk reads:  310 MB in  3.01 seconds = 103.05 MB/sec

хм, у меня dd показал скорость больше, чем hdparm :)

Debian sid/experimental

linux 2.6.32-5-xen-686

Pentium D 915, Intel 945P (Gigabyte GA-8I945P-G), 1GB ОЗУ.

Диск на котором тестировалось Western Digital WDC WD6401AALS-00J7B0

+подключен еще один HDD и DVD-писалка.

тьфу, тестировал я на другом диске - Maxtor 6Y080L0, там же файл ~/test, а хомяки у меня на старом

УМВР.

При записи на диск WDC таких тормозов нет, хотя изредка слегка подергивается мышь.

на bugzilla.kernel.org предлагает кто-то вот такое

# echo 50 > /proc/sys/vm/vfs_cache_pressure

# echo deadline > /sys/block/sda/queue/scheduler

# echo 1 > /sys/block/sda/device/queue_depth

# echo 1024 > /sys/block/sda/queue/nr_requests

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

Баг был, внезапно излечился после vm.swappiness=100. И dd, и копирование больших файлов перестали стопорить гуй.
Прочие параметры:

vm.vfs_cache_pressure=10

echo 4096 > /sys/block/sda/queue/nr_requests
echo 4096 > /sys/block/sdb/queue/nr_requests
echo 4096 > /sys/block/sdc/queue/nr_requests
for i in /sys/block/{h,s}d?/queue/scheduler; do [ -e «${i}» ] && echo 'deadline' >«${i}»; done
echo 99 > /proc/sys/vm/dirty_ratio

Винты — софт-рейд0 на древних WD и сигейте через libata.
IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
ФС — ext4 (barrier=0) и reiserfs.
Арчевское (≈ ванильное) 2.6.33

Короче, во время выполнения команды притормаживает Nautilus. Да и проц четырёхядерный занят более 50%. Пруфпик

Материнка: MSI K9N SLI NVIDIA nForce 570 Chipset
Проц: AMD Phenom 9550 Quad-Core
Хард на который сбрасывался файл — WDC WD15EADS-00S2B0

alex@alex-desktop:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid
alex@alex-desktop:~$ uname -a
Linux alex-desktop 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux

Вывод команд lspci, lspnp, lshw, dmesg.

Также.
Притормаживает гном (фм, менюшки), звук/видео нормально.
МП - Asus P5k
ЦП - Intel(R) Core(TM)2 Quad Q6600 @ 2.40GHz
НЖМД - Samsung-HD403LJ-CT100-12

2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 GNU/Linux

в багзиле полно способов же

у меня нут ставится раком так: добавить торрент с файлами гигов на несколько, попросить кторрент место под них выделить сразу, и 314здец. core duo, 2 gb, i965, винт hitachi. ядра всякие пробовал, начиннная с 2.6.27. в последнем вроде поменьше, но пользоваться системой в таком состоянии нереально. с usb-storage тоже песня, до последнего ядра копирование нескольких гигов на флешку ставило систему раком. с последним ядром не ставит, но скорость такая же низкая