12309

Я о том, что nobody cares

Само собою...

> Есть ли у фри собственные такие эпические баги?

Самое эпичное из того, что недавно фиксили - кернел паник при выдёргивании примонтированной флешки. И отсутствие юникода в консоли. А за текущими багами фри не слежу )

Во фрях этот баг проявляется?

На Фри линуксовый баг 12309 (когда из-за массированного I/O абсолютно ВСЁ встаёт) не проявляется.

Однако в графических приложениях чувствуется некая латентность, но не во всех: например, графический терминал, в котором запущена команда dd с копированием данных блоками по 1ГБ, продолжает воспринимать ввод с клавиатуры как ни в чём не бывало; открытие ссылок на новых вкладках и скроллирование страничек в Firefox происходит с чуть заметной, но не смертельной задержкой; запуск больших приложений, таких как Eclipse и OpenOffice происходит с существенной задержкой по сравнению с нормальным запуском; графический интерфейс Xfce работает чётко и без заметных задержек.

Возможно, хорошее поведение FreeBSD при массированном I/O — это следствие избавления от «GIANT Lock» во всех новых линейках FreeBSD 7-, 8- и 9-й версий, в то мремя, как в Linux похожая техника блокировки «Big Kernel Lock» далека от избавления:Ingo Molnar планирует убить Big Kernel Lock

Недавно Linus вернул реализацию Big Kernel Lock к старому варианту (spinlock), и тем самым потерялась возможность вытеснения. По его словам, единственным приемлемым способом избавиться от задержек является уничтожение Big Kernel Lock из всех 1300+ мест, в которых он используется. Однако, по оценкам Ingo Molnar, с текущими темпами этот процесс может занять порядка 10 лет. Причина: Big Kernel Lock слишком прозрачен. Теперь слишком легко, даже не подозревая об этом, добавить код, который захватывает BKL, и для большинства строк кода никто наверняка не знает, захвачен он в данной строке или нет. Кроме того, автоматическая проверка вложенности блокировок (lockdep) не знает о Big Kernel Lock, и поэтому слишком просто создать труднообнаружимый deadlock.

2008 год. Однако.

>я лишь сказал что ситуация с записью очень большими блоками неестественная.
что? о_О
а кто по-твоему будет разбивать на кусочки многогиговый файл при его копировании с винта на винт, или ещё веселее (выхлоп быстрее во много раз) из оперативы на винт?
вот-вот - НИКТО!

megabaks> а кто по-твоему будет разбивать на кусочки многогиговый файл при его копировании с винта на винт,

А какого размера процесс «ср» при копировании любых больших файлов?

Давай по-другому: как воспроизвести 12309 без dd или его аналога?

элементарно
берём tmpfs размером близким к размеру оперативы, но что бы занятая оператива+tmpfs перекрывало размер оперативы метров на 300-500 минимум
чем угодно забиваем tmpfs ---> 12309
что за данные пофиг - можешь туда большой архив распаковать(но это очень быстро) или много файлов туда залить...

и да - для этого нужен своп

>А какого размера процесс «ср» при копировании любых больших файлов?
о_О?
а cp то каким боком к блокам? скока прочитало, стока и заливает - оно не собирает данные в куски - как есть так и переливает
так же как просто dd if=/bla-bla of=/bla-bla

megabaks> как есть так и переливает
так же как просто dd if=/bla-bla of=/bla-bla

LOL, техническую тему с тобой придется прекратить

При занятой оперативе начнется активный свопинг — это не интересно.

Почему-то при массовой синхронизации двух дисков rsync'ом, когда переливаются десятки Гб 12309 не наблюдается, а IO высокий.

>При занятой оперативе начнется активный свопинг — это не интересно.
а это не нагрузка на I/O? o_O

а ничего что в этом случае есть куча кэшей?
и то что скорости винтов примерно одинаковые тоже ничего?

>начнется активный свопинг

Не у всех есть своп.

Не у всех есть своп.
Ога, и у меня как только 2Га памяти кончается ядро ласково убивает жирдяя лиса. А в случае долгого аптайма или вторым уже Иксы.
Но всем по*уй.

Файрфокс теперь так течёт? Не зря я с него слез..

Расширения к нему жадные. Tab Mix Plus к примеру немеряно ест. А так не только из-за фф, когда проверяю игры новые какие...