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 ()

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

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

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

Напишите свой - который будет писать строго последовательно, - и он нахер никому не будет нужен.

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

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

Куда уж мне до убунтубогов :D

linuxfan ()

Кстати, об "эпичном баге"

Хоть один нытик додумался покачать торренты в tmpfs, и посмотреть, не исчезнут ли тормоза при этом. Или только бесцельно ныть горазды?

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

чуточку притормаживало, но не стопорило систему.

72800+0 записей считано
72800+0 записей написано
скопировано 72800000000 байт (73 GB), 713,789 c, 102 MB/c

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

>а в кривых настройках swapiness, т. к. это единственный io, который может приводить к описываемым проблемам интерактивности.

ага, это при том, что swap отключен ;D

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

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

Потому что: 1) чьи-то шальные ручки могут ызывать fsync; 2) чьи-то кривые ручки могут подкрутить sysctl, урезающий buffers (кеш записи)

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

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

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

>dd if=/dev/zero of=~/file bs=1000000 с noop и при опции sync СОВЕРШЕННО не подвешивает комп!!!

ага, т.к. источник данных - ram(условно), число write-запросов аж 1 =)

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

> в кривых настройках swapiness, т. к. это единственный io, который может приводить к описываемым проблемам интерактивности.

Да нету у меня свопа, нету! Нахрен он нужен на не слишком нагруженном компе с 8гб?)

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

>Может причина не в запросах к диску, а в кривых настройках swapiness, т. к. это единственный io, который может приводить к описываемым проблемам интерактивности.

проверил. дело не только в нём.

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

про это, да, забывать не стоит. а то может порвать диск на части ))

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

> Вот был бы своп - так проблема решилась бы настройкой swapiness инфа 100%, а так - мучайся =)

Типа «нет проблем? Давайте их создадим и героически решим!»?

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

> 2) чьи-то кривые ручки могут подкрутить sysctl, урезающий buffers (кеш записи)

вот это да, нужно править.

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

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

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

>> Squashfs

Add support for lzma and lzo compression

Ну наконец-то, теперь не придётся патчить ваниль..

Придется. Там всего лишь добавлена инфраструктура для их поддержки. Сами они отсутствуют. Так что это дезинформация.

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

там можно долго доказывать «всё_ништяк VS всё_тормозит!»
нужны одинаковые системы в плане софта и разное железо. как поймается такой баг на каком-то чипсете, так сразу и мурыжить его до победы.

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

>для десктопа фрагментация не так страшна, как для сервера

Не скажи. Сильно фрагментированный файл будет выдавать на линейном чтении скорость 1-3 MB/s. Оно тебе надо? Да и распухание числа инодов не может положительно отразиться на производительности.

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

> Фрагментации, к которой ты призываешь, лучше избегать.

Поэтому лучше фапать диск до изнеможения, пожирая ценные IOPs'ы и не давая никому более работать?

Кто мешает от этой самой фрагментации избавиться пост-фактум? Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких (8К и менее).

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

> Да и распухание числа инодов не может положительно отразиться на производительности.

Один файл - один инод, вне зависимости от фрагментации. Или ты о чем-то другом?

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

> потому что баг внезапен и рабочего пока фикса не существует

Этот «внезапный» баг возник ещё в 2.1 и с тех пор не вылечен.

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

Я уже высказывал предположение, правда немного с другой стороны: kernel-девелоперы в большинстве своём я думаю не бедные люди, позволить себе купить десктопную железяку, чтобы воспроизвести баг в своём детище вполне могут, другое дело - что не могут воспроизвести/исправить, или не хотят по неизвестным причинам

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

>Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких

Потери емкости сам посчитаешь?

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

Дык баг воспроизводится на самом топовом железе. Что может быть на десктопе топовее, чем i7 на x58?!

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

>dd if=/dev/zero of=~/file bs=1000000 с noop и при опции sync СОВЕРШЕННО не подвешивает комп!!!

ага, т.к. источник данных - ram(условно), число write-запросов аж 1 =)


а вот и нифига! )
поставил в два потока - тоже всё гуд. поставил в три потока - нет подвисаний и всё тут!
скорость, конечно, разделилась. жесткий еле слышно шумел, как и при одном потоке.

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

> Потери емкости сам посчитаешь?

Не актуально уже давно.

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

>>Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких

Потери емкости сам посчитаешь?

Какие нах потери емкости, если речь идет о торрентах? Да и винты нынче не по 20МБ. Или вы какие-то особенные торренты качаете, из мириад 20-байтных файлов состоящие?

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

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

Но... ты понимаешь сам, что вероятность одновременности этих двух операций в обычной жизни вообще нулевая.

У меня этот баг проявляется только в одном случае: если я пользуюсь встроенным в лаптоп кардриддером. Копирование любого файла >~ 100Mb делает иксы неюзабельными (а так как я скидываю через него свои фотки/видео с камеры, то этот баг бесит меня страшно). Зависит от железа.

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

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

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


У меня в фоне компиляция + запустил вашу «dd if=/dev/zero of=~/file bs=1000000», отзывчивасть упала, но ничего намертво не повисает, только фризы раз в 10 секунд на полсекунды

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

> фризы раз в 10 секунд на полсекунды

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

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

> С таким же успехом «можно смело игнорировать» любые баги.

Ты передо мной права качать надумал что ли? 12309 — не один баг. Если ты никогда не был в шкуре разработчика, тебе не понять, что такое левые репорты, которые засоряют эфир, но к твоему конкретному багу отношения не имеют. Чтобы баг фиксить, надо сначала его идентифицировать, найти «кто виноват», и кто будет чинить. А там просто нытик-тред какой-то.

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

> Ты передо мной права качать надумал что ли?

А ты чем-то отличаешься от остальных? Кровь голубая, пенис 50см?

Если ты никогда не был в шкуре разработчика


Был.

Чтобы баг фиксить, надо сначала его идентифицировать, найти «кто виноват»


Пусть ищут. Там болта положили.

А там просто нытик-тред какой-то


Что накодили, то и фиксить надо. Понятно, что FOSS и всем пофиг чуть более, чем полностью, но тем не менее.


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

>Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких (8К и менее).

И много ты видел фс, созданных с размером кластера больше 4kb?

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

>Ты считаешь это нормальным?

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

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

> Сейчас только проявляется, если писать на жесткий непрерывным потоком

Ага, есть такое. Мне вот пару раз в неделю большие объемы гонять надо, так уже этот 12309 достал...

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

> И много ты видел фс, созданных с размером кластера больше 4kb?

В бытность фат32 мейнстримом знающие делали кластер 16к, достигая таким образом тысячи профита, ибо процессоры были намного слабее.

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

>Один файл - один инод, вне зависимости от фрагментации. Или ты о чем-то другом?

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

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

>И много ты видел фс, созданных с размером кластера больше 4kb?

ну толсто же, в смысле - FAT =)

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

>> Сейчас только проявляется, если писать на жесткий непрерывным потоком, что в повседневности я не делаю

а народ делает

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

>> Да и при больших размерах блоков эффект от фрагментации гораздо менее заметен, чем при мелких (8К и менее).

И много ты видел фс, созданных с размером кластера больше 4kb?

Вендузятник детектед! А еще на бздунов пальцем показывают...

У меня везде, кроме свопа, recordsize по умолчанию - 128К. Все что меньше 128К - занимает ровно столько секторов, сколько требуется, то есть если файл 2,5К или 86,5К- то он и занимает 2,5К или 86,5К.

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

>>Один файл - один инод, вне зависимости от фрагментации. Или ты о чем-то другом?

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

В файловой системе, использующей блоки, размер необходимых метаданных не зависит от расположения блоков, только от их количества (если, конечно, не используются какие-нибудь фокусы типа сжатия метаданных, исключения пустых блоков и т.п.). Вот в системе, использующей экстенты, размер метаданных может существенно отличаться - на непрерывный файл нужен один экстент, на файл из херовой уймы кусков - херова уйма экстентов.

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

>а народ делает

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

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

>> Вендузятник детектед!

Какой молодой ононимус. Тут же каждый тролль знает, что linuxfan вендузятник :)

Вот еще, всякую херню помнить :-)

anonymous ()

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

- Дравйвера индусских видеокарт.

- и еще 100500 строчек ненужного кода.

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

>У меня везде, кроме свопа, recordsize по умолчанию - 128К. Все что меньше 128К - занимает ровно столько секторов, сколько требуется, то есть если файл 2,5К или 86,5К- то он и занимает 2,5К или 86,5К.

и каким образом такого добился? что за фс?

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

> и каким образом такого добился? что за фс?

MetanFS Gazprom Edition

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

> А ты чем-то отличаешься от остальных?

Конечно.

Кровь голубая, пенис 50см?

Нет, у меня в других местах отличия.

Пусть ищут. Там болта положили.

INSUFFICIENT DATA. Я так понимаю, что многим пользователям даже не хочется, чтобы его пофиксили, они тогда не смогут себя представлять в роли жертвы этого бага.

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