Для Linux-ядра представлен (http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ) небольшой патч (http://www.phoronix.com/forums/showpost.php?p=140694&postcou...), заметно повышающий отзывчивость работы интерфейса пользователя при выполнении системой активных дисковых операций. При копировании больших файлов у многих пользователей вызывает раздражение (https://bugzilla.kernel.org/show_bug.cgi?id=12309) ухудшение интерактивности выполнения операций в GNOME, KDE, Xfce и других графических окружениях (например, время реакции на действие пользователя в интерфейсе может достигать нескольких секунд).
URL: http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
Новость: https://www.opennet.ru/opennews/art.shtml?num=27537
ну что, пусть добавляют в ванильное ядро... я думаю все только за будут.
>ну что, пусть добавляют в ванильное ядро... я думаю все только за
>будут.все да не все... основные разработчики ядра больше ориентируются на использоание linux на серверах и им плевать на латентность ядра на десктопах
Вообще говоря Линус очень хочет включить этот патч в ядро потому как он очень сильно оптимизирует некоторые моменты, но ребята занимающиеся VFS против, они хотят всё как следует протестить. Мол да может стать быстрее, но а если что-то отломается другое? Хотя Линус тоже прав - без попадания в одно из rc - этот патч не протестит потенциальное большинство людей
Ну, да. Linux не включал в ядро swap prefetch and bfs.
А почему тут вдруг захотел?
Его супер пупер десткоп на федоре вдруг затормозил :-D
>Ну, да. Linux не включал в ядро swap prefetchКак по мне - при современных объемах оперативы разумнее просто не юзать своп совсем. Тогда и проблемы с его латентностью не будут допекать :)
причём здесь своп? дисковые операции это не только своп.
Ну, swap prefetch - это все-таки своп :)
а этот патч к swap prefetch как-то относится?
Вообще-то в сообщении выше была фраза:
> Ну, да. Linux не включал в ядро swap prefetch and bfs.Которые не относятся к этому патчу, но относятся к латентностям.
> Как по мне - при современных объемах оперативы разумнее просто не юзать своп совсем.Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.
например ?
>> Как по мне - при современных объемах оперативы разумнее просто не юзать своп совсем.
>
>Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.
>вы хотели сказать .Net'ом? А да, проги на дотнете, помимо прочего ещё и только под винду работают...
>>> Как по мне - при современных объемах оперативы разумнее просто не юзать своп совсем.
>>
>>Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.Банк-клиенты (если речь только про десктоп), и большинство бизнес-систем из ряда CRM/ERP, если и про серверы
>вы хотели сказать .Net'ом? А да, проги на дотнете, помимо прочего ещё
>и только под винду работают...откройте для себя уже mono
А лучше закройте и не открывайте. Тормозилки на чем-то полусовместимом с MS - а оно нам надо? :)
>А лучше закройте и не открывайте. Тормозилки на чем-то полусовместимом с MS
>- а оно нам надо? :)не надо, и тем не менее работает не только в винде
>Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.У вас нивелируются? А у меня - нет. Я лучше под дисковые буфера лишнюю память отдам чем под нафигнужные лично мне тормозилки. От тормозилок на яве - тормоза. А от дисковых буферов - ровно наоборот.
>>ну что, пусть добавляют в ванильное ядро... я думаю все только за
>>будут.
>
>все да не все... основные разработчики ядра больше ориентируются на использоание linux
>на серверах и им плевать на латентность ядра на десктопахДа. Это очень печально.
>латентность ядра на десктопахТы сам то хоть понял, что сказал?
Понял, латентность - задержка... А тебя что смущает?
>Понял, латентность - задержка... А тебя что смущает?Вообще есть отличное русской слово "отзывчивость"
>>латентность ядра на десктопах
>
>Ты сам то хоть понял, что сказал?
>
>http://ru.wikipedia.org/wiki/%D0%9B%D0%B...В данном случае это русизм от Latency, а не то, что ты подумал.
просто достаточно добавить опцию в ядро: хотите - используйте. думается, на десктопный вариант вполне себя оправдывает.
Это случайно не исправление ошибки с iowait?
похоже что с этим связано...
У меня этой ошибки нет с чипсетом AMD. А с nvidia есть!!! Насколько я знаю, ошибка с iowait добавлена относительно недавно (год или 2 назад) и трудноуловима
Вот сама ошибка:
https://bugzilla.kernel.org/show_bug.cgi?id=12309
И да, народ тестировал этот патч - это пока не решение проблемы(к сожалению).
А судя по последним комментам - помогает
Да, эта проблема существует.
Также как существует проблема зависания всего интерфейса при открытии сетевого ресурса (который например уже не доступен или до него плохой пинг)...Т.е. получается странная какая-то многозадачность.
>Т.е. получается странная какая-то многозадачность.Какая многозадачность если процессор во время копирования не работает ? В этом-то и проблема.
попробуйте включить DMA, ага
>попробуйте включить DMA, агапочитай про DMA ладно? Он не снижает загрузку процессора - он его ВЫКЛЮЧАЕТ.
за слово "выключает" зачет. Похоже по DMA надо читать именно тебе.
А ничего что DMA уже не существует? И как таковой режим был только у ISA шины ?:) Если ты покажешь мне на PCI шине DMA контролер - я буду очень озадачаен.
И да у шин PCI и выше - похожий режим называется Bus mastering.
>Какая многозадачность если процессорПроцессор и контроллер DMA "реализуют" доступ к разделяемому ресурсу - памяти (это та, что буквой "M" работает в абревиатурах VM и DMA, да?). С букетом вытекающих отсюда локов, гонок, и проч.проблем синхронизации. К этому прибавляем всяческие трансляции адресов, о которых к.DMA знать не знает, но ядро _обязано учитывать, а также особенности и мис-фичи _множества очень различных _шин, чипсетов, мем-контроллеров, и пр., и пр. ...
...уже понятнее, откуда растут сложности и проблемы, и кто тут "школьник"?
>>Какая многозадачность если процессор
>
>Процессор и контроллер DMA "реализуют" доступ к разделяемому ресурсу - памяти (это
>та, что буквой "M" работает в абревиатурах VM и DMA, да?).
>С букетом вытекающих отсюда локов, гонок, и проч.проблем синхронизации. К этому
>прибавляем всяческие трансляции адресов, о которых к.DMA знать не знает, но
>ядро _обязано учитывать, а также особенности и мис-фичи _множества очень различных
>_шин, чипсетов, мем-контроллеров, и пр., и пр. ...
>
>...уже понятнее, откуда растут сложности и проблемы, и кто тут "школьник"?А ничего что контролер DMA существует только на ISA шине?
А для остальных это Bus mastering - для которого доступ к памяти лиш один из режимов ?
>А ничего что контролер DMA существует только на ISA шине?Это с фига ли? Под прямым доступом к памяти (Direct Memory Access, DMA) подразумевается любой доступ к памяти происходящий без участия основного процессора системы. Чисто по определению DMA как явления природы. То что какая-то там ISA и какой-то там контроллер на ней сдохли - мы рады. И что? А вас не смущает что DMA бывает например в ARMовских камнях, у которых вообще НИКОГДА не было никакой ISA шины как класса, равно как и контроллера на этой шине?
>А для остальных это Bus mastering
Bus mastering - это вполне конкретное понятие которым оперирует PCI. А ничего что DMA может существовать на очень разных шинах и механизмах? У какогонить ARM вообще PCI может и не быть. А вот DMA - быть. Нормально так? :)
Блин, два года мучился с этой проблемой на UbuntuStudio :(
и на планировщик cfq патч накладывал - не помагало, теперь вот этот патч пишут что не помагает... :(
>>повышающий отзывчивостьПросто милашкой станет, добрым, отзывчивым :-)
>> время реакции на действие пользователя в интерфейсе может достигать нескольких секунд
В Windows аналогично. Кто-то решил перепаять DMA на что-то другое?
в 7-ке этой проблема решена. в линуксе эта фигня изначально. помню как еще на 2.4.x уже с VM
от АА ( с RVR вообще пепец) запускал на 2 консолях make -j 10 в каталоге с исходниками КДЕ - так вот с третьей консоли войти в систему уже не получалось. это без Х-ов. в отличии от линукса на том же железе на соляре 8-й можно было в скрине запустить 10 (больше не пробовал) таких заданий и система оставалась отзывчивой. это был 2x PIII 2G мозгов.
Доработали до приличия стэк IRP вот и стало более-менее. Хотя CD всё равно мозг выносят? cкорость копирования упала, но что делать. В Mac OS X проблема вообще отсутствовала. Таки BSD.>>это был 2x PIII 2G мозгов.
А причем тут процессор то ? Он в операциях DMA как-бы не участвует.
проблемы в VM причем тут DMA? на одинаковом железе с одинаковым DMA соляра работала нормально, линукс имел проблемы. а железо описано просто для информации. для информации: использую линукс и винду, соляру не использую. т.е. суждение не предвзято.
>соляра работала нормально, линукс имел проблемы.Реализация логики работы с контроллером DMA в защищенном режиме - это вообще-то нетривиальная задача. Вы вообще понимаете как работает DMA?
>>соляра работала нормально, линукс имел проблемы.
>
>Реализация логики работы с контроллером DMA в защищенном режиме - это вообще-то
>нетривиальная задача. Вы вообще понимаете как работает DMA?где вы нашли антиквариат с DMA контролером в наше время ?:)
>в 7-ке этой проблема решена.Да вообще-то тормозит она при активной работе диска. Особенно если диск в системе один. Вплоть до тормозов гуя на полминуты. А если не дай боже в своп что-то выдавилось (а винды очень любят высвапливать программы даже если оперативы еще архидофига свободно) - тут вообще переключение задач может пару минут занять. Сказки не рулят.
А кто может подробно объяснить как наложить этот патч на Debian?
>А кто может подробно объяснить как наложить этот патч на Debian?этот патч накладывают на исходники ядра, а не на дистрибутив...
что за никчемный ответ. иногда лучше промолчать, чем постить пустые коменты.
Ответ абсолютно точный, но совершенно бесполезный.
Как водится.
>А кто может подробно объяснить как наложить этот патч на Debian?как-то так:
Cross your fingers,.
sudo apt-get build-dep linux-source
sudo apt-get install linux-source make-kpkg
cd /usr/src
sudo tar vxf linux-source-2.6.32.tar.bz2
ln -s linux-source-2.6.32 linux
cd linux
cp /boot/config-2.6.32-21-generic ./.configNot sure where to get the patches in a file so you can just wget but
next just...wherever you find the patch files just
patch -p0 < whereverthepatchwas.txtsudo make-kpkg --initrd --append-to-version=-custom kernel-image kernel-headers
you'll find your deb's in the /usr/src
or just
https://help.ubuntu.com/community/Kernel/Compileдумаю, осилишь перевести.
>[оверквотинг удален]
>patch -p0 < whereverthepatchwas.txt
>
>sudo make-kpkg --initrd --append-to-version=-custom kernel-image kernel-headers
>
>you'll find your deb's in the /usr/src
>
>or just
>https://help.ubuntu.com/community/Kernel/Compile
>
>думаю, осилишь перевести.Вау, клево!
Про дебиан понял.
А на убунту как наложить?)
>>patch -p0 < whereverthepatchwas.txt
>Вау, клево!
>Про дебиан понял.
>А на убунту как наложить?)Кляньчить по форумам ссылку на PPA.)
Клянчу. Дайте ссылочку на PPA, плиз =)
>Клянчу. Дайте ссылочку на PPA, плиз =)Идиотизм. Берёшь и патчишь, проприетарные драйверы затем переустанавливаешь. Заодно патч для второго старкрафта наложи.
>>Клянчу. Дайте ссылочку на PPA, плиз =)
>Идиотизм. Берёшь и патчишь, проприетарные драйверы затем переустанавливаешь.Зачем по такой жаре лишний раз нагружать проц? Пусть лучше ланчпадовские сервера греются
>Заодно патч для второго старкрафта наложи.???
Ага. PPA с ядром и патчем для StarCraft, ядро и патч для улучшенной производителоьности сервера, ядро и патч для производительности настольной системы, ядро с какими-нибудь двумя патчами, новое ядро с двумя патчами, ядро с набором патчей от Коливаса... Вам какое? "Яблоко!" "Тьфу! То есть ам." "Мытое яблоко" "А то что, не мытое было?" "Не мытое!" "Тогда то тьфу, а это ам" "Яблоко мытое водой" "Погоди, а то яблоко чем тогда мыто было?" "Ну уж точно не водой!".
О какой нагрузке идёт речь? Вам жалко 20-ти минут на слабом компьютере? Лучше подготовить исходник, залить его на Launchpad, в случае ошибки ещё раз, потом скачтаь пакет и установить?
>Ага. PPA с ядром и патчем для StarCraft, ядро и патч для
>улучшенной производителоьности сервера, ядро и патч для производительности настольной системы, ядро
>с какими-нибудь двумя патчами, новое ядро с двумя патчами, ядро с
>набором патчей от Коливаса... Вам какое? "Яблоко!" "Тьфу! То есть ам."
>"Мытое яблоко" "А то что, не мытое было?" "Не мытое!" "Тогда
>то тьфу, а это ам" "Яблоко мытое водой" "Погоди, а то
>яблоко чем тогда мыто было?" "Ну уж точно не водой!".
>О какой нагрузке идёт речь? Вам жалко 20-ти минут на слабом компьютере?
>Лучше подготовить исходник, залить его на Launchpad, в случае ошибки ещё
>раз, потом скачтаь пакет и установить?Успокойтесь и выдохните. А потом идите и играйте в свой старкрафт
Одна из самых популярных игр на планете. Почему вам не нравится именно эта часть моего сообщения?
Насчёт "выдохните" - классику надо знать: http://www.youtube.com/watch?v=Gsh3MTLqrkQ
>Идиотизм. Берёшь и патчишь, проприетарные драйверы затем переустанавливаешь.Ага, тут +36 за бортом. И дым коромыслом как бонус. Для полноты картины надо еще +100 ватт тепла перед своим носом выдуть, да? Спасибочки, конечно, но пускай другие воздух погреют лучше :). Кстати, у меня кажется нет проприетарных дров в системе. То-есть, мне же меньше геморроя :)
>Заодно патч для второго старкрафта наложи.
Нафиг-нафиг. Как минимум - пусть сперва сделают версию под линух.
# patch -p1 < vmscan.patch
А куда Вы, товарищи, дели BFQ, BFS?
Они не решают проблемы с отзывчивостью?
нет
Вы, право же, шутите. Посмотрите что такое BFQ.
User294>А кто безгрешен? Или какойнить линуксулятор - это типа не костыль?Ещё вспомни о WINE. Ага.
Кстати, на линуксуляторе баг 12309 мне не удалось воспроизвести. Может подскажешь, что нужно сделать? ;)
User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?
Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!
кто знает, когда на опеннете появится функция игнора всяких умников?
Уж лучше так чем карма/инвайты и т.д.
Есть функция "не читать комменты" - все равно они все такие (и этот тоже)
> (и этот тоже)Рекурсия :P
>кто знает, когда на опеннете появится функция игнора всяких умников?Лучше "скрывать _новости и посты в форуме из -другого лагеря-" + деленгие на лагеря: win, lin, bsd, minix, beos, ...... Правда, не понятно, чего делать с взрыв-смесями типа lin+bsd прямо в новости.
Запрещать, как вызывающие межконфессиональную рознь...
> межконфессиональнуюПриравняем *NIXоидство к религии?
>Запрещать, как вызывающие межконфессиональную рознь...Ага, и вообще, лучше оставить какую-нибудь одну систему как расово верную. Правда, чем это потом будет отличаться от MSDN какого-нить?
>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!ext4 - эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в снапшотах и умеет журналирование на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная фряшная UFS2? НИЧЕГО!
>ext4 - эта "пачка костылей и подпорок" обеспечивает продакшенчто весьма печально
>Ещё вспомни о WINE. Ага.Толсто. У меня вообще никакого вине нету например. Он мне не нужен.
>Кстати, на линуксуляторе баг 12309 мне не удалось воспроизвести. Может подскажешь, что нужно сделать? ;)
Пропатчить линукслятор, что же еще? :)
>User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?
>Эта "пачка костылей и подпорок" обеспечивает продакшен,Как-то редко оно в продакшне то встречается. EXTы явно чаще.
>не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС.
А фигли толку, если дизайн ископаемый?
> А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!
Во первых, это умеют другие слои. Во вторых - какая она нафиг суперсовременная? Это шутка такая? Это ж EXT3 на стероидах. Вот только бздуны костылили по принципу "выкрасить и выбросить", навернув много вычурных, красивых и правильных костылей к древней и тупорылой ФС. Не меняющих принципиально свойства ФС, только исправляющие наиболее кондовые грабли в виде "fsck хреначит часами". Получилось академически стройно и нахрен не впившееся на практике. Линуксоиды пролечили журналинг чуть ли не десятилетие назад и потому в этот раз костылили ископаемое исключительно в направлении подъема его скорострельности. Что как раз всем и было надо в основном. В итоге - их старикан с новыми ногами^W^W экстентами - бегает как спортсмен, хоть и не являлся таковым изначально и был нехило перекроен. А некоторые другие не осилили капитально перекроить свою ФС, хотя-бы поюзав экстенты. Если что - экстенты в многих случаях ведут себя намного лучше чем блоки по скорости работы ФС. Именно поэтому их и втыкают в все современные дизайны ФС. Посмотрите на ФС разрабатываемые в последнее время. Все как на подбор юзают экстенты. Ну уж наверное не потому что они дураки, правда? :)
>Как-то редко оно в продакшне то встречается. EXTы явно чаще.Вот-вот. EXT'ы (-2, -3, и -4) — это подпорки и костыли древней как говно мамонта EXT1 начала 1990-х — встречаются куда чаще отрихтованной и доведённой до ума стандартной юниксовой ФС в 2005 году UFS2.
>>не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС.
>
>А фигли толку, если дизайн ископаемый?
>
>> А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!
>
>Во первых, это умеют другие слои.Во-первых, эта отговорка уже не катит. Пока ты склеиваешь необходимые слои между собой и получаешь рабочий снапшот, может пройти очень много времени, что непозволительно для продакшена. К тому же, снапшоты линуксовых ФС нужно делать на неживой-отмонтированной ФС. И, да, скорость записи на раздел со снапшотом в линуксе почему-то проваливается в разы по сравнению с разделом без снапшота. Почему так? Ведь другие нормальные ФС, поддерживающие снимки внутри себя, не страдают от этого дефекта.
>Ext4
>Во вторых - какая она нафиг суперсовременная? Это шутка такая? Это ж EXT3 на стероидах.Вроде и нет больше _современных_универсальных_ ФС в Linux, годных к продакшену. Или я не прав?
>Вот только бздуны костылили по принципу "выкрасить и выбросить", навернув много вычурных, красивых и правильных костылей к древней и тупорылой ФС. Не меняющих принципиально свойства ФС, только исправляющие наиболее кондовые грабли в виде "fsck хреначит часами". Получилось академически стройно и нахрен не впившееся на практике.
Устойчивую к сбоям UFS2, не нуждающуюся для защиты метаданных в журнале ты назвал "кондовыми граблями". Ну-ну. Посмотрел бы я на надёжность современных линуксовых ФС, если ВНЕЗАПНО выключить электричество, а у них не окажется журнала.
>Линуксоиды пролечили журналинг чуть ли не десятилетие назад и потому в этот
>раз костылили ископаемое исключительно в направлении подъема его скорострельности.Журнал необходим для быстрого восстановления после сбоев. Во время нормальной работы он отнимает на себя достаточно заметную долю ресурсов как дисковой подсистемы, так и центрального процессора. Лучше отказаться от журнала вообще и обеспечить механизм внутренней согласованности жизненно важных структур, чем делать подпорки и костыли, тюнинг журналирования.
>Что как раз всем и было надо в основном. В итоге - их
>старикан с новыми ногами^W^W экстентами - бегает как спортсмен, хоть и
>не являлся таковым изначально и был нехило перекроен. А некоторые другие
>не осилили капитально перекроить свою ФС, хотя-бы поюзав экстенты. Если что
>- экстенты в многих случаях ведут себя намного лучше чем блоки
>по скорости работы ФС. Именно поэтому их и втыкают в все
>современные дизайны ФС. Посмотрите на ФС разрабатываемые в последнее время. Все
>как на подбор юзают экстенты. Ну уж наверное не потому что
>они дураки, правда? :)Правда. Потому что экстенты на больших объёмах обслуживаемых данных эффективнее простых битовых карт (сканирование и определение непрерывных цепочек блоков тупо быстрее идёт). Но только на больших объёмах.
>Во-первых, эта отговорка уже не катит. Пока ты склеиваешь необходимые слои между
>собой и получаешь рабочий снапшот, может пройти очень много времени, что
>непозволительно для продакшена.Чаще всего, занимает менее секунды. В чем проблема сделать lock в той же базе данных(при этом доступ на чтение сохранится!), или приостановить, без отказа в обслуживании, виртуалку/контейнер?
> К тому же, снапшоты линуксовых ФС нужно делать
>на неживой-отмонтированной ФС.Глупость, нет такого, Вы что-то перепутали!
самое интересное, что это ему уже тысячу раз писали.
поэтому... ну дайте человеку высказаться. толку то никакого.>User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?
>>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!интересно, а вот это https://www.opennet.ru/base/sys/softupdates_idea.txt.html айзен читал?
>самое интересное, что это ему уже тысячу раз писали.
>поэтому... ну дайте человеку высказаться. толку то никакого.
>
>>User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?
>>>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!
>
>интересно, а вот это https://www.opennet.ru/base/sys/softupdates_idea.txt.html айзен читал?Конечно. Поэтому я говорю о целостности структур метаданных файловой системы, а не данных пользователя.
угу. я так и понял, что это не недоговорённость, а рассчёт на то, что тут все уже научились читать мысли айзена. ну или на худой конец читают между строк:
>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании.
>Конечно. Поэтому я говорю о целостности структур метаданных файловой системы, а не
>данных пользователя.Ну и чем оно принципиально лучше журнала в EXT3 и 4 тогда? Такие допущения и он тоже обеспечивает. Только EXT3 еще и существовал мноооооого лет ;).
интересно другое - когда rc ext4 файлы кед херил, работая в таком же режиме как sf, его айзены хаяли по чём зря. а во фре это уже не баг, а супер фича.
>> К тому же, снапшоты линуксовых ФС нужно делать
>>на неживой-отмонтированной ФС.
>
>Глупость, нет такого, Вы что-то перепутали!Признаю, что-то перепутал. Высказывание касалось только XFS, которую нужно "замораживать" перед снимком. Тем не менее:
http://maximum-value.blogspot.com/2009/01/lvm2.html
"LVM2 и снапшотыМало где говорится о том, что при использовании снапшота в LVM используется неразмеченное пространство в данном томе (Volume), хотя это совсем не очевидно. Т.е. имея 1Gb неразмеченного пространства мы можем сделать снапшот размером до 1G (т.е. и -L1G), но что будет, если мы при этом сделаем снапшот размером 2G и дождёмся, пока он заполнится больше чем на 1Gb?
UPD: снапшот можно сделать размером не более чем неразмеченное пространство в томе, иначе получим "Insufficient free extents"."
— такого маразма нет в UFS2.
>такого маразма нет в UFS2.Интересно, куда девается снапшот, если на диске остался 1Mb и не размеченая в 1Gb?
А ты попросил создать 2G снапшот? Может поверх данных писать начнёт?
>>такого маразма нет в UFS2.
>
>Интересно, куда девается снапшот, если на диске остался 1Mb и не размеченая
>в 1Gb?
>А ты попросил создать 2G снапшот? Может поверх данных писать начнёт?в снапшотах ufs2 не нужны всякие не размеченные области, так же как и не нужно говорить какого объема создавать снапшот - удивитесь.
один хрен при нехватке места снепшота не будет.
просто тут процесс контролируется, а у вас нет.
>и не нужно говорить какого объема создавать снапшот - удивитесь.Удивляюсь :)
BSD создали для того, чтоб человек думал, а не машина...
эх, где мои счётные палочки с гидроподъёмником.
>Высказывание касалось только XFS, которую нужно "замораживать" перед снимком.Уже не нужно
>как говно мамонта EXT1 начала 1990-хВсе так. Только к EXT4 старикана так перепилили что оригинал и не узнать. Тут вам и экстенты, и хешированные директории, и отложенное выделение. В общем все как у большинства иных подобных ФС типа XFS, JFS, etc. Не свежак и не последний писк, но и параметры не позорные. Весьма резвая такая ФС. И отлаженная временем.
> — встречаются куда чаще
Угадаете с трех раз почему? Наверное секрет в том что с хешированными дирами и экстентами - параметры EXT4 даже похожи на что-то приличное.
>отрихтованной и доведённой до ума стандартной юниксовой ФС в 2005 году UFS2.
Что-то никому этот ваш UFS2 как файловая система толком не нужен. Может быть, это потому что дисковые структуры недалеко ушли от "говна мамонта", со всеми вытекающими, как то неважненькая производительность на ряде нагрузок?
>>Во первых, это умеют другие слои.
>Во-первых, эта отговорка уже не катит.Это зависит от того шашечки или ехать. Если цель разрулить задачу - это одно. Если подрочить на академически правильное решение - другое.
>Пока ты склеиваешь необходимые слои между собой и получаешь рабочий снапшот,
>может пройти очень много времени, что непозволительно для продакшена.А мужики то не знают. Странно. Наверное iZEN им не попадался. Упущеньице.
>К тому же, снапшоты линуксовых ФС нужно делать на неживой-отмонтированной ФС.
Откуда это следует?
>И, да, скорость записи на раздел со снапшотом в линуксе почему-то проваливается
>в разы по сравнению с разделом без снапшота. Почему так?Вам анонимаус объяснял вроде? Это было безрезультатно? При том он объяснял что однозначно выигрышной стратегии нет, IIRC.
>Ведь другие нормальные ФС, поддерживающие снимки внутри себя, не страдают от этого дефекта.
Да, конечно, btrfs какойнить так работает что снимки - просто его логика работы. Это впрочем не означает что у него других проблем не будет.
>Вроде и нет больше _современных_универсальных_ ФС в Linux, годных к продакшену. Или
>я не прав?XFS тот же - он может и не суперуниверсал, но на ряде применений (большие файлы, etc) очень так ничего. И на несколько дисков размазывается хорошо, чем ext4 похвастать не может.
>Устойчивую к сбоям UFS2, не нуждающуюся для защиты метаданных в журнале ты
>назвал "кондовыми граблями".Про ее устойчивость к сбоям вам имхо доступно рассказали в соседнем посте. Вот у настоящих CoW файловых систем с недеструктивной записью - там да, устойчивость к сбоям есть. На уровне устройства ФС, так что и файлы и метаданные можно вернуть к какому-то предсказуемому состоянию, исключив ситуации "запись обломалась на середине - файл наполовину перезаписан".
>Ну-ну. Посмотрел бы я на надёжность современных линуксовых ФС, если ВНЕЗАПНО
>выключить электричество, а у них не окажется журнала.И даже с журналом - гарантируется непротиворечивое состояние журнала и структур ФС. А вот что будет с файлами - вопрос номер два. Гарантию атомарности записи данных + метаданных в классических ФС дает полное журналирование. А оно тормозное из-за двойной операции записи.
>Журнал необходим для быстрого восстановления после сбоев. Во время нормальной работы он
>отнимает на себя достаточно заметную долю ресурсов как дисковой подсистемы,Если журналятся только метаданные - то не отнимает. Обычно все соглашаются на такой вот компромисс. В итоге тормоза могут возникать только при metadata-intensive workload'ах. А это довольно нишевые и не частые случаи (именно поэтому кстати вырубить всякие там времена доступа - отличная идея).
>так и центрального процессора. Лучше отказаться от журнала вообще и обеспечить механизм
>внутренней согласованности жизненно важных структур,Насколько я понял спич по любезно приведенной в соседнем сообщении ссылке - механизм soft-updates в UFS2 не обещает что если я записывал файл и если все фигакнулось в момент записи то у меня будет или старый файл, или новый. А не нечто, наполовину старое и наполовину новое, не факт что юзабельное вообще.
>чем делать подпорки и костыли, тюнинг журналирования.
Строго говоря - я не без причин полагаю что будущее за ФС с недеструктивной записью, т.е. CoW-подобными файловыми системами. У них конечно своих грабель навалом, однако их плюсы в виде недеструктивности и возможности хранить более 1 версии файла - явно перевешивают.
>>Ну уж наверное не потому что они дураки, правда? :)
>Правда. Потому что экстенты на больших объёмах обслуживаемых данных эффективнее
>простых битовых карт (сканирование и определение непрерывных цепочек блоков
>тупо быстрее идёт). Но только на больших объёмах.А объемы данных растут, если вы не заметили. Ноутбячный винч размером полпачки сигарет в терабайт никого уже не удивляет.
>>как говно мамонта EXT1 начала 1990-х
>
>Все так. Только к EXT4 старикана так перепилили что оригинал и не
>узнать.Ага. Аж оторопь порой берёт: http://www.linux.org.ru/forum/general/5205490
"ext4 не видит суперблока после сбоя питаниясобственно, сбоев было два и второй, похоже, на проверке после первого... я особо не следил. комп в режиме 24 на 7. выключился - я включил, ушел. скорее всего была проверка пока уходил. вернулся - все опять выключено. (само оно у меня не включается, но это другая история)
после включения в GRUBе выбрал тот самый сбойнувший Debian, а он не смог найти раздел. стоит также Mandriva, в нее и загрузился. слил убитый рутовый раздел dd-шкой в образ, благо он всего 40 гиг. и стал пытаться гуглить и восстановить. fsck.ext4 -y /dev/sdd1 лечил около часа, в итоге все в лост+фаунд с непотребными именами.
залил обратно из образа. при запуске так же предлагает чистить и чинить. тут с отказной опцией: [root@sg mnt]# fsck.ext4 -n /dev/sdd1 e2fsck 1.41.4 (27-Jan-2009) fsck.ext4: Superblock invalid, trying backup blocks... Superblock has an invalid journal (inode 8). Clear? no fsck.ext4: Illegal inode number while checking ext3 journal for /dev/sdd1
если подсунуть другой суперблок: [root@sg mnt]# fsck.ext4 -nb 8193 /dev/sdd1 e2fsck 1.41.4 (27-Jan-2009) fsck.ext4: Bad magic number in super-block while trying to open /dev/sdd1 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device>
также пробовал подставлять 8193, 24577, 40961, 57345, 73729, взятые из статьи: http://breys.ru/blog/297.html - результат тот же.
при этом fdisk все видит правильно: [root@sg mnt]# fdisk -l /dev/sdd Диск /dev/sdd: 1000.2 ГБ, 1000203804160 байт 255 heads, 63 sectors/track, 121601 cylinders Units = цилиндры of 16065 * 512 = 8225280 bytes Disk identifier: 0x37abde1d Устр-во Загр Начало Конец Блоки Id Система /dev/sdd1 1 4864 39070048+ 83 Linux /dev/sdd2 4865 121601 937689952+ 5 Расширенный /dev/sdd5 4865 121601 937689921 83 Linux
а gparted не опознает файловую систему на том разделе.
зы. модераторам. перед написанием сообщения на форум предлагаете читать FAQ - ссылка мертвая (404).
sunny178 (08.08.2010 21:30:58) "Весело у вас. :)
>Ага. Аж оторопь порой берёт: http://www.linux.org.ru/forum/general/5205490
>"ext4 не видит суперблока после сбоя питанияАга, только вот...
1) Не указан кернел. Кернелы до .30 ... .32 с EXT4 вообще будет юзать только мазохист.
2) У чувака довольно старая версия ext2 утилсов. У меня вот например e2fsck 1.41.11 на десктопе в кубунте.
3) Там маловато информации о том что за ФС, какие фичи юзались, какая конфигурация системы, что произошло, кто и насколько виноват и прочая. Например "а gparted не опознает файловую систему на том разделе" наводит на разные мысли. Могла допустим таблица разделов попортиться и все смещения съехали. Если сунуться 5 раз в неверные данные - разумеется суперблок там будет "порушен". А человек глазами то смотрел - а есть ли суперблок в том месте в котором он ищет вообще? А то может там вообще были не суперблоки? :)
4) Если тщательно прикапываться - ну нате вам в вашем же духе, например http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/... Наверняка еще что-то такое нагуглится запросто (но меньше чем EXT4 - сколько его юзает народа, а сколько UFS2?). Или вы как наивный чукотский юноша думали что качественно убить при сомнительных обстоятельствах можно только EXT4? Да хрен там, практически что угодно можно уложить при правильном подходе к делу. А EXTовские утили к слову одни из наиболее настырных. Они пытаются что-то отскрести даже там где чекалки других ФС сдаются. EXT4 в этом плане доверия поменьше чем EXT3, в силу новизны структур. Однако по информации как тут - даже не понятно кто виноват и багу например не напишешь.[skip]
Не обязательно сюда все сообщение цитировать, имхо - читатели явно могут по ссылке пройти.
Ждём в zen-kernel.
Кажеться, дело движется к разделению ядра на сервер/десктоп форки.
Сразу, как только Линус почкованием разделится, ага.....
>Кажеться, дело движется к разделению ядра на сервер/десктоп форки.Только форкать будут дистрибутивы. В меру своих хотелок. И, главное, они и так это делают по жизни - мало кто ванильное ядро юзает совсем без изменений.
Это еще зачем? Одно будет, если же конфиг.
>Это еще зачем? Одно будет, если же конфиг.*есть
И эти люди агитируют за линукс на десктопах, со всеми его детскими болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов. Вы девочке на ресепшне вот это всё объясните
sudo apt-get build-dep linux-source
sudo apt-get install linux-source make-kpkg
cd /usr/src
sudo tar vxf linux-source-2.6.32.tar.bz2
ln -s linux-source-2.6.32 linux
cd linux
cp /boot/config-2.6.32-21-generic ./.config
Not sure where to get the patches in a file so you can just wget but
next just...
wherever you find the patch files just
patch -p0 < whereverthepatchwas.txt
sudo make-kpkg --initrd --append-to-version=-custom kernel-image kernel-headers
Патч установился на 2.6.32? :)
>Патч установился на 2.6.32? :)Суровая девушка на ресепшене попалась)
Бедняжка.
Вот с этим парнем вы одинаково мыслите, видимо.
http://www.bannedinhollywood.com/wp-content/uploads/2010/05/...
> И эти люди агитируют за линукс на десктопах, со всеми его детскими болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов. Вы девочке на ресепшне вот это всё объяснитеи эти люди агитируют нас за Windows. Вы тетеньке-бухгалтеру обьяснити как устанавливать SQL сервер и 1С и как в нем запрограммировать форму или отчет или как установить и настроить клиент-банк! Да они сами даже принтер или мышь не подключат к компьютеру!
SQL сервер и 1С в итоге работают, а сабжевый костыль - как обычно
https://www.opennet.ru/openforum/vsluhforumID3/69590.html#6
https://www.opennet.ru/openforum/vsluhforumID3/69590.html#69
ну и чего тогда так волнуешься? оно тебе нужно? или ты таким образом волонтёром винды работаешь?
мне вот не нужно. хоть линух полностью вытеснил винду уж лет как 5 на моих десктопах. мне другие, волее важные моменты интересны.зы:
ща народ может расскажет, как бысто вызвать диспетчер задач в загруженной винде?
а то порой такая "отзывчивость" наступает, что несколько минут составляет.
правда когда диспетчер всё-таки открывается, то загрузка уже ниже 30% и что грузило его так долго остается тайной.
Тогда, быть может, его имеет смысл держать свернутым на фоне?
>имеет смысл держать свернутым на фоне?пара занимаемых метров погоды не делают, это вам не тормознутый gnome system monitor
бесполезно. не помогает.
по всему видно, что он просто ждёт освобождения неких ресурсов.
>бесполезно. не помогает.
>по всему видно, что он просто ждёт освобождения неких ресурсов.подтверждаю, много много раз на 2k3
>И эти люди агитируют за линукс на десктопах, со всеми его детскими болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов. Вы девочке на ресепшне вот это всё объяснитеВы и есть та девочка на ресепшне?
>чтобы перестал виснуть при копировании файлов.Ядро 2.6.33.5, не виснет, брат жив.
У девушки на ресепшене для этого есть тех саппорт в компании или на крайняк фирма, облуживающая их компанию, не? Или вы думаете на винде она тоже сама чистит всякие темпы, гоняет вирусню, инсталлит принтеры и т.д. и т.п.?Хватит уже этим маразмом болеть про домохозяек и блондинок.
Большая часть юзверей венды даж не знаю как антивирь запустить на скан системы.
не. у них девушки на ресепшене сами ставят винды, сами гоняют вирусы, сами фильтруют/рассылают спам.
а они, айтишнеГи, только ходят, надувают щеки, дышат перегаром.
Ага, а ещё они предлагали школьникам самостоятельно обслуживать свой школьный линапс. И каждый блин школьник вместо прогулок на свежем воздухе будет сидеть в душной аудитории и накладывать патч за патчем, пытаясь привести глючную ось в рабочее состояние.
не патчи, а апдэйты. боюсь на винды патчи не выпускаются.
впрочем как и на бинарные дистры.
да не видел я ни разу чтоб играли в wow на свежем воздухе.
короче, популистский, тупой тролинг.
>И эти люди агитируют за линукс на десктопах, со всеми его детскими
>болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов.
>Вы девочке на ресепшне вот это всё объяснитеЗдесь сайт для любитлей и профессионалов.
Патч не решает проблему. Совсем.Убунта 10.04, ваниль + патч.
>Патч не решает проблему. Совсем.
>
>Убунта 10.04, ваниль + патч.Убунта 10.04 искаропки. Древний Dell Dimension 9100 = Pentium D + SATA. Ядро 2.6.32-24-generic когда-то приползло с апдейтом, никаких патчей.
Проблема c dd напрочь отсутствует.
Пробовал pipes and processes от Томаса Пиларски - заметно подтормаживает, что неудивительно при 104 активных процессах, latency не больше 0.2 сек.
min:0.012ms|avg:0.012-0.013ms|mid:0.013ms|max:195.542ms|duration:69.787s
Както недавно писал образ двд на 8 гиг. 3,5 часа!!! И при этом системной не возможно было пользоваться. 12309 такая 12309 :(
баг с iowait исправят когда redhat свистнет - инфа 100%
те как обычно, лет через пять. а пока добавляются драйвера 1001 левого железа,ведется борьба с нарушителями gpl и форкается 1001 дистрибутив.
У Торвальдса баг на федоре не проявляется. Т.о. статус бага сейчас поменяется на WORKSFORME
https://bugzilla.kernel.org/page.cgi?id=fields.html#status
>У Торвальдса баг на федоре не проявляется. Т.о. статус бага сейчас поменяется
>на WORKSFORME
>https://bugzilla.kernel.org/page.cgi?id=fields.html#statusсомневаюсь что им удается держать Торвальдса в неведении... ;)
Не это главное. Разрушен внутренний мир многих людей считавших, что Linux самая лучшая ОС на планете, вот что печально. Это же миллионы покалеченных судеб!
Это из другой песни.
проблема исчезает, если монтировать ФС с опцией sync
>проблема исчезает, если монтировать ФС с опцией sync:) Тормозить так уж всем сразу?
можно ещё atime, diratime, barrier (где есть), norelatime, wsync (XFS), align
А есть кто-нибудь, у кого эта бага не проявляется. Я вообще не понимаю о чем разговор. Ни разу не видел, чтобы на недревнем железе были тормоза из-за копирования. Объясните как репродуцировать проблему, какая файловая система должна быть, какое ядро, видяха, видеодрайвер, версия иксов, какой SATA(PATA) контроллер используется, какой чипсет в конце концов? Если это про ntfs-3g и iowait, то не интересно.
А то так написано, как будто это повсеместное явления, а у меня ни на одном компе не наблюдается, я уже 10 dd запустил и в наутилусе копировал в несколько потоков и болванку нарезал одновременно и нормально десктоп работает.
Правда иксы пропатченные, может быть в этом дело?
>А есть кто-нибудь, у кого эта бага не проявляетсяiZEN
>Объясните как репродуцировать проблему
на лоре есть тред
только потом не жалуйся, когда машина зависнет минут на *дцать
>на лоре есть тредurl?
судь в
dd if=/dev/zero of=/some/file bs=8M
С параметрами дд можно поиграть. Заметишь сразу, если у тебя оно есть, т.е. люди даже ctrl+c не могут иногда нажать из-за диких тормозов, или ждут пока команда сработает секунт 10-30.
>судь в
>dd if=/dev/zero of=/some/file bs=8M
>С параметрами дд можно поиграть. Заметишь сразу, если у тебя оно есть,
>т.е. люди даже ctrl+c не могут иногда нажать из-за диких тормозов,
>или ждут пока команда сработает секунт 10-30.у меня имеено такие симптомы, но только при записи на usb flash (возможно и usb hdd)
Как я понял, это не один баг. Просто проявляется аналогично. Там все в куче- железо, какие то регрессии, еще что-то. Есть всякие разные методы, которые одним помогают, другим нет. Можешь поискать, глядишь чего-нить да поможет. :)
>dd if=/dev/zero of=/some/file bs=8MЗапустил. Индикатор винта на моем ветре горит, файлик делает.
А я пишу это сообщение. ЧЯДНТ?
>>dd if=/dev/zero of=/some/file bs=8M
>
>Запустил. Индикатор винта на моем ветре горит, файлик делает.
>А я пишу это сообщение. ЧЯДНТ?система должна, для начала, полезть в своп! (а потом уже пробовать dd)
она это делает?
Да смешно конечно.
Посмотрел, что ЛОРе предлагают, и в багзилле. Я такое уже делал и одновременно кино смотрел и никаких даже секундных подтормаживаний.
Короче ясно, это не мой случай. Убунта 10.04 и Debian lenny.
Вот я одного не могу понять, почему считается, что баг в ядре, если тормозят только DE и то не все? Может быть там какие-то десктопные фишки, которые 'file' регулярно запускают на измененном файле, или превьюхи пытаются генерить, или размер файлов подсчитывать "незаметно", не?
или бигли и прочии индексаторы какие-нибудь стоят. я к примеру их сразу сношу.
описываемые траблы ниразу не встречал.
>[оверквотинг удален]
>понимаю о чем разговор. Ни разу не видел, чтобы на недревнем
>железе были тормоза из-за копирования. Объясните как репродуцировать проблему, какая файловая
>система должна быть, какое ядро, видяха, видеодрайвер, версия иксов, какой SATA(PATA)
>контроллер используется, какой чипсет в конце концов? Если это про ntfs-3g
> и iowait, то не интересно.
>А то так написано, как будто это повсеместное явления, а у меня
>ни на одном компе не наблюдается, я уже 10 dd запустил
>и в наутилусе копировал в несколько потоков и болванку нарезал одновременно
>и нормально десктоп работает.
>Правда иксы пропатченные, может быть в этом дело?у меня эта штука проявлялась сразу после того как система в своп начинает лезть - при обработке большого видео проекта в cinelerra + большое колличество дисковых операций, например когда deluge чекал торренты... потом в "делуге" что-то поправили что бы он типа в один поток к винту обращался...
один раз пришлось даже reset нажать - потому что 45 минут ожидания при попытке перейти в консоль CTRL+ALT+F1 (что бы убить процесс душащий систему) не хватило терпения... :(
Точно такие же пирожки, если памяти осталось пшик, то все замирает, приходится резет или MagicSysRq юзать, по другому баг не проявляется, диски/флешки нормально пишутся.
>А есть кто-нибудь, у кого эта бага не проявляется.Поищи обсуждение этого бага, например на Опеннете. Увидишь, что он возникает в зависимости от железа и его драйвера чипсета.
>А есть кто-нибудь, у кого эта бага не проявляется. Я вообще неТы походу хотел спросить у кого она проявляется. Я такого не видел со времён Pentium 4 HT.
Сегодня не поленился проверить - ни на одной доступной железяке воспроизвести не удалось.
>Ты походу хотел спросить у кого она проявляется.Я вообще не хотел спрашивать, пока не почитал каменты, из которых неявно следовало, что все отписавшиеся имели счастие наблюдать это явление.
баг проявляется на чипсетах nforce(2, 4). я гарантирую это.
>баг проявляется на чипсетах nforce(2, 4). я гарантирую это.у меня на ноуте Dell Vostro 1400 проявлялся - на других не замечал, но там Intel чипсет...
nForce4 SLI - никаких проявлений в течении 4х лет.
>баг проявляется на чипсетах nforce(2, 4). я гарантирую это.Кровью подпишешь?
-----------
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
02:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce GTS 250] (rev a2)
10:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
10:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
10:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
10:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
11:04.0 Co-processor: Broadcom Corporation BCM5820 Crypto Accelerator (rev 10)
80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3)
80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
81:00.0 Ethernet controller: Agere Systems ET-131x PCI-E Ethernet Controller (rev 02)
Надеюсь знаете, что CK804 - это nForce4? Так вот, сижу пишу эту хрень,
на консоли делается dd if=/dev/zero of=BIGFILE count=1024 bs=32M,
ффокс играет ролик на утрубе при 1080p http://www.youtube.com/watch?v=HuD1X0QPhWM
top показывает 18% утилизации на двух ядрах.
А RAM у вас сколько? А в своп что-нибудь сбрасывается или он пустой? К тому же в оригинальном тесте надо записывать по 1М за раз (а у вас 32М). А какие параметры в /proc/sys/vm/swappiness и /proc/sys/vm/vfs_cache_pressure? Так много вопросов потому что у меня тоже чипсет CK804. Проблема дает о себе знать когда заканчивается RAM (256M).
>А RAM у вас сколько? А в своп что-нибудь сбрасывается или он
>пустой? К тому же в оригинальном тесте надо записывать по 1М
>за раз (а у вас 32М). А какие параметры в /proc/sys/vm/swappiness
>и /proc/sys/vm/vfs_cache_pressure? Так много вопросов потому что у меня тоже чипсет
>CK804. Проблема дает о себе знать когда заканчивается RAM (256M).Да уж... 256 это ещё не минимум, но уже хреново. :)
------
dd if=/dev/zero of=BIGFILE count=32768 bs=1M
32768+0 записей считано
32768+0 записей написано
скопировано 34359738368 байт (34 GB), 131,577 c, 261 MB/c------
RAM 4Gb DDR2 ECC PC3200 Registred
-----
vm.swappiness = 0
vm.vfs_cache_pressure = 1000
у меня при активной записи на usb flash (особенно в несколько потоков/на несколько flash) остальные приложения могут "подвиснуть" (судя по всему на io).патч борется именно с этой проблемой?
>у меня при активной записи на usb flash (особенно в несколько потоков/на
>несколько flash) остальные приложения могут "подвиснуть" (судя по всему на io).
>
>
>патч борется именно с этой проблемой?э-э-э-э с флешками это отдельная тема...
некоторые флешки просто не умеют в несколько потоков писать. а что после этого происходит - хз.
>некоторые флешки просто не умеют в несколько потоков писать. а что после
>этого происходит - хз.ну так пусть и тормозит запись на flash, к этой части у меня никаких претензий нет.
только почему переключение на соседний xterm может занять несколько секунд? (в случае параллельной записи на две тормозные флешки)
>>некоторые флешки просто не умеют в несколько потоков писать. а что после
>>этого происходит - хз.
>
>ну так пусть и тормозит запись на flash, к этой части у
>меня никаких претензий нет.
>только почему переключение на соседний xterm может занять несколько секунд? (в случае
>параллельной записи на две тормозные флешки)потому что есть понятие очереди...
и кто знает - что произойдет если вся очередь забьется кусками только для флешек?
>потому что есть понятие очереди...
>и кто знает - что произойдет если вся очередь забьется кусками только
>для флешек?разве не отдельная очередь для каждого блочного устройства?
>>потому что есть понятие очереди...
>>и кто знает - что произойдет если вся очередь забьется кусками только
>>для флешек?
>
>разве не отдельная очередь для каждого блочного устройства?я так понимаю что сразу это всё попадает в очередь планировщика ( noop anticipatory deadline cfq ) а уже потом в очереди блочных устройств...
>некоторые флешки просто не умеют в несколько потоков писатьА почему же некоторые? АН flash-диски всегда нужно записывать данные только в один поток, и использовать не журналируемую файловую систему
На домашней машине никогда этот баг не проявлялся, зато на рабочей такой тупняк даже когда система немного свопится - курсор не двигается, и этот патч кстати не помог.
Попробовал у себя. Забавно это все работает :)
Раньше периодически сталкивался с такими тормозами, но только сейчас дошли руки оттестить и локализовать проблему.
Eee pc 901, ssd, atom
Соответственно reiserfs, nolog, noatime, elevator=deadline, sd[a-b]->fifo_batch=1, vm.swappiness=0, swap offxxx@xxxbook:~$ uname -a
Linux ormbook 2.6.30-02063010-generic #02063010 SMP Fri Dec 4 10:49:55 UTC 2009 i686 GNU/LinuxЗапускал в два потока
sudo dd if=/dev/zero of=/home/test[12].tst bs=8M count=100
И смотрел на отзывчивость при работе с /home и в целом, наблюдал iostat 1 и vmstat 1Выяснил примерно следующее:
1. Явно есть какие то гонки при одновременном доступе на запись нескольких потоков к одному устройству (в моем случае - sdb), на работе остальных дисковых устройств отражается несильно (sda например)
2. Суммарная скорость записи обоих потоков значительно (30% и больше) меньше чем скорость записи одного потока, что по идее на SSD быть не должно.
3. Если допустим в gedit открыт файл на редактирование (в /home естественно) и попытаться его сохранить, gedit зависает до окончания записи обоих потоков.
4. Если перемонтировать /home в sync, скорость записи несколько снижается. (спасибо К.О.! :) )
5. Но при перемонтировании в sync в том же gedit зависание происходит не до конца записи, а на 3-5 секунд. Т.е. появляется хоть какая то отзывчивость.
6. В любом режиме (и sync и async) из bash командами вида "echo xxx > /home/test.txt" или "cat /home/test.txt" все работает достаточно быстро, без тормозов.Вывобы примерно такие - проблема в где то в записи метаданных. sync позволяет её несколько сгладить (очередь не успевает переполниться видимо). Проблема видимо возникает не при любой записи, а только при записи с определенными флагами (bash же не вис, вис только gedit, хотя может я ошибаюсь) - нужно посмотреть как именно выполняет запись gedit и как bash в исходниках и написать пару тестовых бинарников для проверки.
Для себя я решил просто поставить sync - флешка все равно умрет рано или поздно, +-30-40% скорости записи мне не роляют. А вот сидеть и ждать, пока какой нить образ на флешку зальется - весьма нехочется, были прицеденты.
>Для себя я решил просто поставить sync - флешка все равно умрет
>рано или поздно, +-30-40% скорости записи мне не роляют. А вот
>сидеть и ждать, пока какой нить образ на флешку зальется -
>весьма нехочется, были прицеденты.вместо sync еще можно попробовать такой способ
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 4096 > /sys/block/sda/queue/nr_requests
echo 4096 > /sys/block/sda/queue/read_ahead_kb
echo 100 > /proc/sys/vm/swappiness
echo 0 > /proc/sys/vm/dirty_ratio
echo 0 > /proc/sys/vm/dirty_background_ratioпроверено - у меня работает ))
>echo 100 > /proc/sys/vm/swappinessНу это вообще не для меня. Как я писал, у меня ssd и свопа нет, крутить этот параметр смысла нет.
>echo 10 > /proc/sys/vm/vfs_cache_pressure
Опять же, как я понял этот параметр как и предыдущий работает только если есть своп. Хотя толкового описания его работы я не нашел, прям хоть в исходники лезь.
>echo 4096 > /sys/block/sda/queue/read_ahead_kb
Тоже на SSD нахрен не нужно, у меня стоит 256 кв. Где то в инете было тестирование влияния RA при работе с SSD, я от него отталкивался.
>echo 4096 > /sys/block/sda/queue/nr_requests
Потом потестирую, может быть как нить влияет. Кто нить знает, как посмотреть сколько запросов в очереди дискового шедулера к устройству sda в данный момент времени? Было бы интересно помониторить при нагрузке.
>echo 0 > /proc/sys/vm/dirty_ratio
>echo 0 > /proc/sys/vm/dirty_background_ratioПосмотрим, может что и родится.
>проверено - у меня работает ))
Что то у меня ощущения, что у тебя работает в силу других причин, или просто тестишь неправильно. Ибо из того, что ты назвал - может влиять на эту проблему (в варианте как описал я) - только может быть nr_requests,dirty_ratio,dirty_background_ratio
>>echo 100 > /proc/sys/vm/swappiness
>
>Ну это вообще не для меня. Как я писал, у меня ssd
>и свопа нет, крутить этот параметр смысла нет.
>
>>echo 10 > /proc/sys/vm/vfs_cache_pressure
>
>Опять же, как я понял этот параметр как и предыдущий работает только
>если есть своп.Не, это VFS
vfs_cache_pressure
------------------Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.At the default value of vfs_cache_pressure=100 the kernel will attempt to
reclaim dentries and inodes at a "fair" rate with respect to pagecache and
swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer
to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
never reclaim dentries and inodes due to memory pressure and this can easily
lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
causes the kernel to prefer to reclaim dentries and inodes.
>>echo 4096 > /sys/block/sda/queue/read_ahead_kb
>Тоже на SSD нахрен не нужно, у меня стоит 256 кв. Где
>то в инете было тестирование влияния RA при работе с SSD,
>я от него отталкивался.
>
>>echo 4096 > /sys/block/sda/queue/nr_requests
>
>Потом потестирую, может быть как нить влияет. Кто нить знает, как посмотреть
>сколько запросов в очереди дискового шедулера к устройству sda в данный
>момент времени? Было бы интересно помониторить при нагрузке.Sadomazo версия
# cat /proc/diskstatsКлассика
# iostat -x>>echo 0 > /proc/sys/vm/dirty_ratio
>>echo 0 > /proc/sys/vm/dirty_background_ratio0 - это сурово :)
>[оверквотинг удален]
>------------------
>Controls the tendency of the kernel to reclaim the memory which is used for
>caching of directory and inode objects.
>At the default value of vfs_cache_pressure=100 the kernel will attempt to
>reclaim dentries and inodes at a "fair" rate with respect to pagecache and
>swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer
>to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
>never reclaim dentries and inodes due to memory pressure and this can easily
>lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
>causes the kernel to prefer to reclaim dentries and inodes.Что и требовалось доказать - если нет свопа, значит и конкуренции между "dentries and inodes" и "pagecache and swapcache" нет. Т.е. если все действительно работает как написано (что вовсе не есть факт) - разницы от кручения этого параметра быть не должно.
>>Кто нить знает, как посмотреть
>>сколько запросов в очереди дискового шедулера к устройству sda в данный
>>момент времени? Было бы интересно помониторить при нагрузке.
>Sadomazo версия
># cat /proc/diskstats
>Классика
># iostat -xСпасибо
>>>echo 0 > /proc/sys/vm/dirty_ratio
>>>echo 0 > /proc/sys/vm/dirty_background_ratio
>0 - это сурово :)Вот и мне показалось несколько подозрительным. Тестить надо =)
Кстати покопавшись в крутилках, подумал что в моем случае (нетбук на atom и ssd без свопа, fs в sync) имеет смысл уменьшить /sys/block/sd[ab]/queue/iosched/write_expire до 2500 с дефолтных 5000, или даже меньше (например 2000 или 1500).
Но пока только поставил, еще не тестил.Как я понял, write_expire в моем случае и есть максимальное время, на которое может зависнуть тот же gedit при записи файла на раздел, на который уже ведется интенсивная запись в другом потоке.
>>[оверквотинг удален]
>Что и требовалось доказать - если нет свопа, значит и конкуренции между
>"dentries and inodes" и "pagecache and swapcache" нет.Своп - это нечто иное как продолжение Виртуальной памяти.
vm.swappiness - задаёт вероятность включения в работу дискового свопа.
И не надо его боятся, при данном параметре, от 0 до 10, своп заработает
только при полном заполнении оперативки.
........Эх, надо ФАК написать по sysctl -w vm.*
>>>[оверквотинг удален]
>>Что и требовалось доказать - если нет свопа, значит и конкуренции между
>>"dentries and inodes" и "pagecache and swapcache" нет.
>Своп - это нечто иное как продолжение Виртуальной памяти.
>vm.swappiness - задаёт вероятность включения в работу дискового свопа.
>И не надо его боятся, при данном параметре, от 0 до 10,
>своп заработает
>только при полном заполнении оперативки.Да в общем то словоблудие все это.
В моем случае свопа нет и он не нужен. Плюс это лишняя неизвесная в работе системы (в которой судя по комментам к 12309 есть баг, проявляющийся при нагрузке).
Вопрос только, насколько корректно в подсистеме vm обрабатывается случай отсутствия свопа вообще, и соответственно насколько полно отключаются куски кода, не нужные в данной ситуации (а в данном случае - еще и потенциально тормозящие и имеющие баг). Все таки отсутствие свопа - не совсем стандартный случай ;)>Эх, надо ФАК написать по sysctl -w vm.*
Напиши, я думаю многим не хватает толкового описания на понятном русском как работают эти крутилки. Особенно с примерами из практики, что на что влияет ;)
Потестил еще
Выяснил интересный момент, не очевидный с первого взгляда.
У меня (atom, ssd, fs sync) параметр fifo_batch стоял в 1. Выяснилось, что если его вернуть в дефолтные 16, скорость линейной записи в ОДИН поток возрастает примерно в два раза, а на отзывчивости и на записи в два потока это сказывается несильно - как зависал gedit на 5-10 секунд, так и виснет, скорость двух потоков тоже меняется не более чем на 10%.В общем то нелогичное поведение, учитывая что при тестах в режиме sync количество записанных транзакций в секунду больше 100 было редко - соответственно нагрузка на обсчет этого всего должна быть минимальной (речь идет о линейной записи в один поток).
В общем странно.
Учтите это, если у кого будет похожая конфигурация (sync fs, elevator=deadline).P.S. nr_requests c дефолтных 128 увеличил до 512, его длины явно не хватало как я понял из iostat. На результатах заметным образом это не сказалось.
2.6.35 патч не помог если память кончается и ядро лезет в своп начинаются жуткие тормоза, курсор тормозит, выод картинки в tvtime тоже, загрузка проца не более 40%, комп старый амд 1,6 ГГц 1,25 Г память, чипсет VIA.
Если это и баг, то из другой оперы совершенно. ИМХО если оперативка заканчивается и все начинает тормозить и нагрузка на диск резко возрастает из-за свопа, это вполне нормальное явление.
Здесь вроде бы просто про активные дисковые операции разговор.
>Если это и баг, то из другой оперы совершенно. ИМХО если оперативка
>заканчивается и все начинает тормозить и нагрузка на диск резко возрастает
>из-за свопа, это вполне нормальное явление.
>Здесь вроде бы просто про активные дисковые операции разговор.Да не, в исходной новости разговор как раз про своп, патч внимательнее посмотрите.
Просто мы с павлинуксом в соседней ветке обсуждаем мою ситуацию, где свопа нет. Она похожа, но корни другие.Вообще, в баге 12309 ядра линукса кроется несколько багов на самом деле как я понял. Эти баги проявляются в похожих ситуациях (при нагрузке и на границе исчерпания свободной памяти) и выглядят похоже (подвисания и тормоза), но имеют разные причины.
Bug 12309 - Large I/O operations result in poor interactive performance and high iowait times
Это не про своп на границе исчерпанной памяти. То что свопинг может вызвать Large I/O operations это понятно. Но там где именно этот баг, проявляться он будет не только при свопе.
Ну а то что все похожие тормоза начали обзывать багом 12309, это я уже понял и об этом и написал. И кстати представленный патч насколько я понял не помог никому, у кого действительно Large I/O operations вызывают тормоза, а не закончившаяся оперативка.
>Если это и баг, то из другой оперы совершенно. ИМХО если оперативка
>заканчивается и все начинает тормозить и нагрузка на диск резко возрастает
>из-за свопа, это вполне нормальное явление.
>Здесь вроде бы просто про активные дисковые операции разговор.это далеко не нормальное явление!
операции со свопом - дисковых операций тоже касаются.
так что проблема одного характера...