LINUX.ORG.RU

Linux 2.6.34 Released!

 , , ,


0

0

В ночь с 16 на 17 вышел релиз стабильного ядра Linux!

В этой версии ядра добавлены:

  • 2 новых файловых системы: Ceph и LogFS - распределённая ФС и ФС для Flash устройств.
  • Добавлен драйвер для VMware Balloon
  • Много улучшений btrfs
  • Асинхронное засыпание/пробуждение
  • Поддержка переключения видеокарт
  • Базовая поддержка Radeon Evergreen (Radeon HD 5xxx)
  • Базовая поддержка энергосбережения для radeon r600 с kms
  • Виртуальные сети: быстрые KVM сети
  • TTL механизм безопасности VLAN Proxy ARP

>>> Полный список

★★★★★

Проверено: maxcom ()
Последнее исправление: helios (всего исправлений: 3)

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

a_no_no
()
Ответ на: комментарий от pekmop1024

AMD, да? :)

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

anonymous
()
Ответ на: комментарий от a_no_no

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

a_no_no
()
Ответ на: комментарий от linuxfan

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

Kompilainenn ★★★★★
()
Ответ на: комментарий от linuxfan

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

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

anonymous
()

> LogFS

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

Deleted
()
Ответ на: комментарий от no-dashi

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

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

------

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

Andrew-R ★★★★★
()
Ответ на: комментарий от Deleted

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

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

anonymous
()
Ответ на: комментарий от Casus

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

Casus ★★★★★
()
Ответ на: комментарий от matumba

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

apt-get install btrfs-tools

xtron
()

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

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

nt_crasher ★★★
()
Ответ на: комментарий от a_no_no

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

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

Casus ★★★★★
()

Ждём в Debian Stable.

anonymous
()
Ответ на: Double logo при загрузке от nt_crasher

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

post-factum ★★★★★
()
Ответ на: комментарий от Kompilainenn

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

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

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

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

linuxfan
()
Ответ на: комментарий от linuxfan

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

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

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

Fracta1L
()
Ответ на: комментарий от anonymous

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

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

linuxfan
()
Ответ на: комментарий от Fracta1L

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

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

linuxfan
()

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

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

sprutos ★★★
()
Ответ на: комментарий от KevinDetry

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

anonymous
()
Ответ на: комментарий от Casus

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

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от Fracta1L

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

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от Fracta1L

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

sprutos ★★★
()
Ответ на: комментарий от Fracta1L

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

OH SH~~

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

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от linuxfan

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

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

anonymous
()
Ответ на: комментарий от nikotyn

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

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

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

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

linuxfan
()
Ответ на: комментарий от Fracta1L

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

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

linuxfan
()
Ответ на: комментарий от Fracta1L

> нафиг?

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

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

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

Fracta1L
()
Ответ на: комментарий от Fracta1L

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

sprutos ★★★
()
Ответ на: комментарий от Fracta1L

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

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

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

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

Fracta1L
()
Ответ на: комментарий от linuxfan

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

frame ★★★
()
Ответ на: комментарий от Fracta1L

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

sprutos ★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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-клиент.

Andrew-R ★★★★★
()
Ответ на: комментарий от linuxfan

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

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

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

nikotyn
()

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

sprutos ★★★
()
Ответ на: комментарий от linuxfan

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

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

VoDA ★★
()
Ответ на: комментарий от frame

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

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

linuxfan
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.