/me много годов ждет preload в шедулере (хоть в каком) а то дельфин после долгого ничего не делания с системой грузится секунды 2-3.

AMD, да? :)

Штеудераст детектед.Вынос мозга.

У меня кстати под zen-kernel нвидия блоб не поднялся, не понравилось. Неужто переустановку дров нужно в этом случае?

а ничего что 25 мегабит/с приблизительно = 3 мегабайта/с....а ты ему про 80 мегаБАЙТ/с скорость записи ХДД расписываешь...нуну...даже запись множества мелких кусочков не понизит скорость записи ТАК радикально

> Качается торрент — что это значит? Это значит «много перемещений головки и записи мелкими кусочками».

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

> LogFS

Она только для SSD? Или, если судить по названию, её можно и на /var/log/, например, накатить?

уже есть в тестинге

> Со времён ядра 2,6,17 (Мандрива 2007) моя флешка не изменилась.

А ты ее контроллер с пристрастием допроси, много интересного узнешь, насколько она «не изменилась».

------

И как это сделать? Какой-нибудь варинт smart-for-scsi , или нечто специфичное, в обход блочного устройства и скази-протокола вообще?

> Или, если судить по названию, её можно и на /var/log/, например, накатить?

По названию судить не надо, это они прикалываются так - типа Journaling Flash Filesystem 2 на самом деле журнально-структурированная файловая система, а не журналирующая, поэтому нам надо тоже всех обмануть своим названием, поэтому LogFS а никакой журнальной структурой не пахнет.

Кстати, 80Мб/с диск можно довести до 1Мб/с, если шаблон I/O будет случайным. SSD на запись тоже могут притормозить в случайный момент времни для сборки мусора. Остальные проблемы так же нуждаются в сортировке, чтобы понять кто виноват и что же в итоге чинить.

>Мужики, а как эту BTRFS заюзать? Вот скомпилю я ведро, а чем мне разделы форматить?

apt-get install btrfs-tools

Double logo при загрузке

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

> me много годов ждет preload в шедулере

Ты так и ждёшь, ядро «за много годов» так и не менял? В этом плане там, однако, были переделки...

Ждём в Debian Stable.

Количество пингвинов == количество ядер. Открути одно ядро — будет один пингвин =).

>а ничего что 25 мегабит/с приблизительно = 3 мегабайта/с....а ты ему про 80 мегаБАЙТ/с скорость записи ХДД расписываешь...

А ничего, что 80 мегабайт — это линейная скорость записи, которой разве что dd if=/dev/zero of=/dev/sda достичь?

даже запись множества мелких кусочков не понизит скорость записи ТАК радикально

Именно так радикально и понизит. И iowait подскочит не по-джентельменски.

>А ничего, что 80 мегабайт — это линейная скорость записи, которой разве что dd if=/dev/zero of=/dev/sda достичь?

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

а ты тут про какие-то жалкие 80

>Ну это справедливо только для файловых систем из прошлого века. Пользуйтесь современными файловыми системами, и не придется фапать диск

Еще один. Даже если ты делаешь выделение файла единым куском, запись происходит в разные его участки. Отсюда куча перемещений головки и как результат отвратительно низкая производительность.

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

Ой, а вот еще один, не знающий о дисковом кеше. Ты еще дисковод откопай и похвастайся всем, что на флопик пишет со скоростью 80 метров в секунду.

Двоечник, 25Мбит/с ≈ 3Мб/с, а у винта 80. Плюс ко всему ktorrent пишет на отдельный винт.

echo noop > /sys/block/sda/queue/scheduler
или
echo deadline > /sys/block/sda/queue/scheduler

может спасти владельцов шедулеротита

> Можно вроде правило для HAL'а прописать
В новой убунте для этого нужно править исходники udisks. И никак иначе
Тоже самое касается кривы прав доступа для FAT по умолчанию. В убунту об этом знают, но исправить сторку кода так трудно...

> Так что 12309 можно смело игнорировать.

С таким же успехом «можно смело игнорировать» любые баги. Баг присутствует и подтвержден людьми со всего мира. Неуловимый, сложный? А никто и не говорил, что ты в сказку попал, берясь за разработку ядра.

а какая мне разница, задействует он кэш или нет? пишет? пишет. Быстро? быстро. Что тебе ещё надо?

> а какая мне разница, задействует он кэш или нет? пишет? пишет. Быстро? быстро. Что тебе ещё надо?

Попробуй отмонтировать и посмотреть, сколько времени займет сброс кэшей

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

большая такая разница. попробуй сразу после записи отмонтировать раздел, куда эта запись шла. гы. еще проверь скорость с параметром «sync» в монтировании, вот уж ты удивишьсо )))

> при выключении компьютера

OH SH~~

[cat@Monster ~]$ uptime
15:21:59 up 19 days, 14:57, 3 users, load average: 0.36, 0.55, 0.94

По существу - время жизни кэшей невелико, попробуй отмонтировать сразу после копирования.

> Даже если ты делаешь выделение файла единым куском, запись происходит в разные его участки. Отсюда куча перемещений головки и как результат отвратительно низкая производительность.

Мальчик, ты застрял в прошлом веке - то что ты говоришь, справедливо для таких ярких представителей прошлого столетия, как extX, UFS, FFS, VxFS и прочих. Осиль уже, как работают btrfs или zfs, на худой конец.

>Двоечник, 25Мбит/с ≈ 3Мб/с, а у винта 80

Я знаю, что такое мегабит и чем он отличается от мегабайта. А вот ты разницу между линейной скоростью записи и seek + write, видимо, не в состоянии осознать?

Плюс ко всему ktorrent пишет на отдельный винт.

Итак, ktorrent пишет на отдельный винт и в ответ вся система тормозит?

>попробуй сразу после записи отмонтировать раздел

нафиг?

познаешь, что такое кэш ))))

Разницу можно ощутить при отмонтировании, исчерпании памяти под кеш и особенно она чувствуется при потере питания.

Я, кстати, не жалуюсь на какой-то эпический баг. У меня-то все летает.

> нафиг?

На флэшки обычно копируют и достают их сразу. Чтобы унести. А не ждут часами, пока система сбросит кэши. А если ОЗУ >= 8ГБ, кэши могут не сбрасываться по полдня

я и так знаю

я просто не понимаю ваших жалоб на низкую скорость работы с винтом

принудительный sync тебе поможет

только причём здесь флэшки, если про винты речь шла?

да я и не жалуюсь. дело не в этом. проверь-ка осторожно, не начинает притормаживать система при «dd if=/dev/zero of=~/file bs=1000000»

притормаживает - это мягко сказано -))

гуй намертво повисает

> я просто не понимаю ваших жалоб на низкую скорость работы с винтом

Скорость-то нормальная, просто линуксом пользоваться в это время нельзя. Ибо не откликается морда.

а, вот это да

а если так выставить?
echo noop > /sys/block/sda/queue/scheduler

bfq в этом плане отлично спасал

только из 2.6.33-zen его куда-то выпилили

у меня и так noop

Уже очень продолжительное время драйверы многих FS работают не в режиме sync, т.е. используют кеширование записи. Суть бага в том, что поток запросов к подсистеме ввода-вывода в последний ядрах убивает интерастивность чуть более, чем полностью

а у меня повседневно deadline, а с noop просто меньше тормоза показались. или это всё бред...

> Качается торрент — что это значит? Это значит «много перемещений головки и записи мелкими кусочками».

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

------------

Для ФС из прошлого века тоже кое-что сделали:

vmscan: Factor out page reference checks (help workloads with large amounts of shortly used file mappings, like rtorrent hashing a file or git when dealing with loose objects)

так что в каком-то смысле «фапает» тут именно *torrent-клиент.

> Я знаю, что такое мегабит и чем он отличается от мегабайта. А вот ты разницу между линейной скоростью записи и seek + write, видимо, не в состоянии осознать?

Итак, ktorrent пишет на отдельный винт и в ответ вся система тормозит?

Ни ты, ни твои познания не представляют для меня никакого интереса.

продолжаю эксперименты )
dd if=/dev/zero of=~/file bs=1000000 с noop и при опции sync СОВЕРШЕННО не подвешивает комп!!! только вот скорость, сами понимаете...

> А теперь, внимание: strace -e open -c your-favorite-application и посмотри, сколько же там скрыто обращений к диску и почему это должно работать быстро, когда Ktorrent задрачивает несчастную железку?

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

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

Запускаю торренты и emerge на компиляцию рядышком. Никаких проблем с интерактивностью, но приложения стартуют помедленней и фф странички рендерит не так шутсро, что вполне естественно. Может причина не в запросах к диску, а в кривых настройках swapiness, т. к. это единственный io, который может приводить к описываемым проблемам интерактивности.