Хм...

fox@darkstar:~/Temp$ gcc -O3 fsync-tester.c 
fox@darkstar:~/Temp$ gcc --version | head -n 1
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

Хм... У меня они нормально удалились, от обычного юзера

>могу ещё пару раз запустить параллельно с какими-нить io, напр с фтп кучу файлов покачать :)

интереснее всё-таки на незагруженной системе

это нормально?

у меня без ворнингов собиралось. Хз

всё разобрался надо было написать

fd = open(«fsync-tester.tst-file», O_WRONLY|O_CREAT,S_IRWXU|S_IRWXG);

Во время работы несколько раз замирал FF, где то секунды на 2-3, остальное вроде все нормально ворочалось

http://pastebin.com/m5bff1685

Ага, спасибо.

http://pastebin.org/68671

Симптомы точь как при каче торрентов. Своп не юзался ни разу (по gkrellm-у следил).

ещё раз с O3 потестировал всё тоже самое 0.6 - 2.5. Подвисания если и были то много меньше секунды, что не напрягало.

/usr/local/bin/a.out | wgetpaste
Your paste can be seen here: http://dpaste.com/137716/

Это после echo 1 > /proc/sys/vm/drop_caches && sync && swapoff

Таки почему оно может сегфолтится?

gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4 (точно рабочий, вся система собрана им)

Пробовал разные -O и -march=

GDB говорит:

Program received signal SIGSEGV, Segmentation fault.
0x08048a53 in main ()

>Во время работы несколько раз замирал FF, где то секунды на 2-3, остальное вроде все нормально ворочалось

собственно, «тормознутость» FF - это одно из проявлений проблемы fsync на больших файлах. Потому что sqlite. У гажима, подозреваю, причина подвисаний - тоже использование sqlite

Мерз секунд на 12. Неужели при внутренней-то скорости в 50 M io/s не имеет права?

>Таки почему оно может сегфолтится?

фиг знает. Может скопипастил криво?

просто gcc 'fsync-tester.c -o fsync-tester' пробовал?

>Может скопипастил криво?

Это проверил в первую очередь. И собирается ровно (пробовал с -v), без ворнингов.

просто gcc 'fsync-tester.c -o fsync-tester' пробовал?

Да.

Я грешу на файлухи. Проси постить не только дистр, но и io-шедулер, файлухи(у меня он влиял). Я уменьшал влияние бага путём кручения vm.dirty_ratio

Кстати после окончания FF повис и скрипел дисками с небольшой скоростью 1 M io/s пока я не потёр созданные программой fsync*-и.

Получается что дело во фрагментированности исходного диска?

http://rn0.ru/raw/893/
Тупило всё, что хоть как-то связано с дисковой активностью, всё остальное просто подтормаживало.

А патч или что-то там, исправляющий, уже есть? :)

Я не запускал, но уверен, что баг есть

Я вообще запускал на чистом разделе, который никем кроме теста не использовался.

>А патч или что-то там, исправляющий, уже есть? :)

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

>Я грешу на файлухи.

я тоже грешил. Пока не воткнул в бук чистый винт, куда поставил кармик. До этого дефрагментировал ext3, в итоге сейчас ext4, баг никуда не делся. Шедулеры пробовал разные - нет изменений.

кстати, тем, у кого ext4 и баг - немного поможет опция монтирования nobarrier.

Я уменьшал влияние бага путём кручения vm.dirty_ratio

в какую сторону крутил?

ну и хотелось бы не уменьшить влияние, а вообще избавиться от бага.

>Получается что дело во фрагментированности исходного диска?

к сожалению нет. Иначе проблема бы решалась переустановкой системы с нуля.

http://paste.org.ru/?6mmtzj

З.Ы. Файл убавил до 1гб, т.к. места свободного нету, фризы были, когда переключал рабочие столы (особенно там где фф)

>ну и хотелось бы не уменьшить влияние, а вообще избавиться от бага.

ps: ну или придти к заключению, что это не баг, а фича. by design, так сказать.

+ у меня еще при создании файла скролинг фризится в фф
++ слава богу кто то взялся за ум, об этом баге половина лора плачет

Уменьшил размер файлика в 8 раз (ну нету места у меня, нету) и получил вот такой прикольный результат.

setting up random write file
done setting up random write file
starting random io!
starting fsync run
fsync time: 9.9228s
fsync time: 30.8786s
fsync time: 1.0695s
fsync time: 1.6866s
fsync time: 1.2149s
run done 5 fsyncs total, killing random writer

Запускал несколько раз на винте, который никем не юзается - никаких фризов. Запускал в $HOME - тормозят только те, кто лезет на ФС. Ведро 2.6.32 amd64.

А у тебя какой чипсет?

http://pastebin.ca/1726948
вот на таких древностях мы сидим. Тормозов особых не заметил, учитывая что у меня процессорный вентилятор подвывает от колесика мыши, я к ним привык.

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

starting fsync run
starting random io!
fsync time: 0.1436s
fsync time: 1.7171s
fsync time: 0.7371s
fsync time: 1.2810s
fsync time: 1.0058s
fsync time: 0.4588s
fsync time: 2.0133s
fsync time: 0.9279s
fsync time: 1.4578s
fsync time: 0.9346s
fsync time: 1.5051s
fsync time: 1.2508s
fsync time: 1.1299s
run done 13 fsyncs total, killing random writer

В этот раз тормоза были больше. Если это имеет значение, это все на софт-рейде 5.

AMD Phenom(tm) II X4 925 Processor (2.8 ггц)

моя теория — баги в acpi

всем пробовать acpi_os_name=«Microsoft Windows» ядру при загрузке

У меня acpi в ядре нет вообще. А баг есть.

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

И скажи мне значение параметра в BOIS P'nP OS yes/no

fsync time: 0.2046s
fsync time: 0.0180s
fsync time: 0.0904s
fsync time: 0.1740s
fsync time: 0.0269s
fsync time: 0.3518s
fsync time: 0.1208s
fsync time: 0.0832s
fsync time: 0.0379s

Музыка как играла, так и играет. Гуй тоже не тормозит

Debian GNU/Linux squeeze/sid

 uptime && uname -r && lspci 
 23:42:39 up  4:53,  4 users,  load average: 0.17, 0.31, 0.90
2.6.31.2-mybuild
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
02:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

На убунте 9.04 на очень древнем десктопе:
http://paste.org.ru/?lxtc2k
Тормозов почти не было

Сомнительно.
Когда впервые зарелизилось ядро с CFQ - все радовались, эта бага исчезла.
Потом постепенно вернулась.
Очень зависит от железа, я на своём нетбуке практически не замечаю сейчас.
Раньше был hp nx7300 - там было заметнее в разы, но с тех пор и ядра поменялись сильно.

Ну смотри: бага в том, что ядро проводит недопустимо много времени в каком-то привилегированном участке, причем невытесняемом. Что такого в системе происходит, когда есть интенсивный I/O? Появляется много аппаратных прерываний от DMA-контоллера, которыми он уведомляет систему о необходимости считать данные из буфера. Где-то тут и тормозит. Я грешу на проблемы с обработчиками прерываний, а acpi тут может играть не последнюю роль ввиду того, что ей отдали распределение номеров прерываний и диапазонов ввода-вывода.

>линакс

Марш к логопеду, быдло!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ух ты, логопед разморозился :)

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

хз, я в этих низкоуровневых вещах не слишком силён. Имел в виду что grep -i acpi /usr/src/linux/.config ничего не показывает (все соответствующие опции в ядре отключены).

P'nP OS

Нет вроде такого. Есть что-то типа «special PnP for PCI», установлена в «disabled». Материнка на nForce3.

acpi_os_name=«Microsoft Windows» ничего не изменило, и у меня аптайм похоже не влияет: сразу после загрузки системы 5-секундные фризы при включенном тесте и fsync time 1-7 секунд

http://paste.org/pastebin/view/13504

Жуткие лаги

предварительные мысли:

баг есть у всех. Но проявляется он по разному, и зависит от того, как сконфигурирована система - какая fs, её фрагментация, кешируется ли запись журнала и есть ли он вообще, опции noatime, nomtime, кол-во ядер цпу (при отключении второго ядра, например - тормоза становятся сильно меньше), размер оперативки и активность свопа, размер буферов, частота сброса на диск, кол-во одновременно читающих/пишущих процессов, включено ли ncq (выставление размера очереди в 1 тоже улучшает ситуацию)

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

подозреваю, что косяк где-то в управлении очередью i/o. Может, дисковая подсистема стала очень умной, и ждет - не прилетит ли ещё запрос, который можно выполнить одновременно с уже имеющимися,а может - запросы на запись вставляются в начало очереди, как самые важные, в результате чего запрос на чтение файла вызывает запись atime + до кучи сброс залежалого товара в своп + ещё что-нибудь. В итоге ядро проводит 90% времени в iowait

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

зы: у самого чипсеты 945 и 965 - на обоих бага есть, масштабы отличаются незначительно.

кому невмоготу, пробуйте и наблюдайте за изменениями:

для всех fs - noatime
для ext4 - noatime, nobarrier
echo 1 > /sys/class/block/<диск>/queue/nr_requests
echo 99 > /proc/sys/vm/dirty_ratio

> подозреваю, что косяк где-то в управлении очередью i/o

Косяки с очередью наблюдались бы без привязки к чипсетам.

Кроме того, вот эта информация

945 и 965

никакого смысла не несет, потому что за дисковое I/O отвечает южный мост, к которому могут еще дискретные контроллеры отвечать. Так что мое предложение — у тех, кого баг проявляется явно и безоговорочно должны выяснить, к порту какого контроллера у них подсоединен их диск, название, и модель желательно. Вот это будет адекватный сбор информации.

Пока под подозрениями южные мосты от Nvidia, но это нужно проверять.

Про себя: Дисковая система на

SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH)

IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03)

ведет себя нормально.

> к которому могут еще дискретные контроллеры отвечать.

к которому могут еще дискретные контроллеры быть присоединены

Да, кстати, всю логику планировщика можно отключить, выбрав планировщик noop. Он, как я понимаю, вообще никакого переупорядочивания запросов не делает. Пробуйте его тогда!

да пробовал. Отключение планировщика в общем-то никак не влияет на само существование очереди запросов. Даже если запросы не группировать и не объединять.

все опробованные планировщики i/o - noop, anticipatory, cfq, deadline, bfq - никак не влияют на баг

>Косяки с очередью наблюдались бы без привязки к чипсетам.

так они и не привязаны.

Пока под подозрениями южные мосты от Nvidia, но это нужно проверять.

думаю, ни при чём тут nvidia.

965 -
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 03)

на 945 соответсвенно интеловский же мост не помню точную маркировку (ICH7 чототам) - бук выключен сейчас

у меня вообще из компов с компонентами от nvidia - бук со сломанной рамкой монитора в разобранном состоянии в шкафу

> так они и не привязаны.

Неправда! У кучи народа никаких проблем нет. По крайней мере, в этом аспекте.

Кстати, вот еще вспомнил: аццкие тормоза случались при перегреве жесткого, когда он насильно парковал головки при высокой температуре.