Линус Торвальдс представил (https://lkml.org/lkml/2012/3/18/132) релиз ядра Linux 3.3 (http://www.kernel.org). Из основных улучшений можно отметить интеграцию изменений, подготовленных в процессе разработки платформы Android, поддержку новой архитектуры TI C6X, включение наработок по борьбе с негативным влиянием промежуточной буферизации пакетов (Bufferbloat), улучшенную реализацию RAID в Btrfs, возможность изменения размера ФС Ext4 на лету, интеграция кода виртуального коммутатора Open vSwitch, более масштабируемая альтернатива драйверу агрегации сетевых линков ("bonding"), новые средства для управления сетевыми приоритетами и ограничения TCP-буфера в привязке к cgroup.
В новую версию принято около 9 тысяч исправлений от более тысячи разработчиков, размер патча - 43 Мб (для сравнения, размер патча ядра 3.2 - 99 Мб, 3.1 - 49 Мб, 3.0 - 44 Мб). Добавлено 10753 тыс. строк кода, удалено - 10698 тыс. строк. Около 40% всех представленных в 3.3
изменений связаны с драйверами устройств, примерно 26% изменений имеют
отношение к обновлению кода специфичного для аппаратных архитектур, 12% связано с сетевым стеком, 5% - файловыми системами и 4% c внутренними подсистемами ядра.
Ядро 3.3 также примечательно преодолением очередного рубежа - размер исходного кода ядра превысил отметку в 15 млн строк. При этом 5.6 млн строк приходится на драйверы, 1.8 млн на специфичный для аппаратных архитектур код, 700 тыс на файловые системы, 533 тыс на звуковую подсистему, 493 тыс на сетевой стек. 97.22% кода ядра написано на языке Си, 2.47% на ассемблере, 0.15% на Perl и 0.04% на Shell. Отметка в 10 млн строк была пройдена в конце 2008 года, при выпуске ядра 2.6.27.Наиболее интересные новшества (http://kernelnewbies.org/Linux_3.3) ядра 3.3:
-
Системные сервисы
- Интеграция (https://www.opennet.ru/opennews/art.shtml?num=32630) некоторых улучшений и исправлений, подготовленных для ядра, используемого в платформе Android. В частности, перенесена поддержка ashmem (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6... (реализация разделяемой памяти, позволяющая маркировать незакреплённые страницы памяти, которые в последующем можно освободить в ситуации нехватки свободной памяти), механизма межпроцессного взаимодействия Binder IPC, ram console (возможность сохранить вывод консоли в специальной области ОЗУ, к которой можно получить доступ после перезагрузки в режиме диагностики), специализированного драйвера для ведения системного лога, реализации LMK (low memory killer, управление принудительным завершением приложений в случае нехватки памяти), вариант драйвера gpio. Некоторые подсистемы ядра Android, например wakelocks, пока остаются неперенесёнными, но в конечном итоге в будущем планируется добиться интеграции всех наработок из ядра Android, что существенно упростит сопровождение кода, позволит сконцентрироваться на одном ядре при разработке драйверов и даст возможность использования последней версии ядра Linux при портировании Android;- Поддержка загрузки с использованием EFI (http://ru.wikipedia.org/wiki/Extensible_Firmware_Interface) (Extensible Firmware Interface). В состав ядра включен набор компонентов, необходимых для загрузки и запуска образа ядра (x86 bzImage) непосредственно прошивкой EFI. Образ ядра bzImage выглядит для прошивки как приложение EFI. При этом, созданный образ bzImage является универсальным и кроме поддержки EFI может использоваться без изменений и с классическими загрузчиками, вызываемыми из BIOS;
- Интеграция патча, который решает проблемы с повышенным потреблением энергии на ноутбуках, поддерживающих технологию ASPM (Active State Power Management) для карт PCI Express. Проблема проявляется начиная с ядра 2.6.38, в котором была реализована новая система инициализации ASPM, и проявляется в повышении энергопотребления на 10-30%. Предложенный патч имитирует поведение Windows Vista при инициализации системы управления питанием, т.е. не очищает статус ASPM для всех устройств в процессе загрузки, оставляя параметры, выставленные BIOS. В феврале данный патч уже был распространён (https://www.opennet.ru/opennews/art.shtml?num=33013) для прошлых версий ядра в виде обновлений 3.0.20 и 3.2.5;- Поддержка технологии DMA-BUF для совместного использования буферов. Используя DMA-BUF различные подсистемы ядра (V4L2, DRI и т.п.) могут совместно использовать буферы между различными драйверами устройств;
-
Дисковая подсистема, ввод/вывод и файловые системы
- Расширение возможностей файловой системы Btrfs:
- Полностью переработанная реализация операции балансировки ("balance"), используемая для полной перезаписи данных файловой системы, в чём возникает необходимость, например, при добавлении дополнительного диска, на который следует перераспределить уже имеющиеся в ФС данные. Таким образом операция балансировки позволяет привести ФС в сбалансированное состояние, но обычно перестроение является длительной операцией и занимает много часов. При этом новая реализация кода балансировки поддерживает возможность приостановки процесса и его последующего возобновления, а также возможность вывода подробной информации о статусе выполнения операции. Процесс балансировки теперь основан на использовании профилей данных и метаданных, что позволяет организовать балансировку только пустых групп блоков.
- Поддержка перестроения данных (restriping) между различными RAID-уровнями (т.е. можно перейти от одного типа RAID на другой). Поддержка новой возможности реализована в ветке "parser" инструментария btrfs-progs;
- Новая отладочная утилита "integrity check", предназначенная для расширенного тестирования целостности данных разработчиками ФС в процессе выявления ошибок. Суть тестирования состоит в обеспечении дополнительного слежения за соблюдением непротиворечивности записываемых на диск данных, выявляя ситуации при которых возможно нарушение целостности ФС;
- Новая реализация механизма изменения размера ФС Ext4. В отличие от существующей в настоящее время системы изменения размера, новый механизм полностью реализован в ядре, а потому работает намного быстрее. В тестах производительности он значительно обогнал прошлую реализацию, позволив изменить размер файловой системы, с 20 Гб до 230 Гб за 3.3 секунды, вместо более чем 5 минут, которые понадобились утилите resize2fs. Для выполнения изменения размера в ядро был добавлен новый ioctl EXT4_IOC_RESIZE_FS;
-
Сетевая подсистема
- Альтернативная реализация системы агрегирования сетевых интерфейсов. Реализовано новое сетевое устройство "teaming (http://git.kernel.org/linus/3d249d4ca7d0ed6629a135ea1ea21c72... изначально позиционируемое как быстрая, масштабируемая, прозрачная и управляемая из пространства пользователя замена механизму "bonding". Teaming позволяет создавать виртуальные сетевые интерфейсы, объединяющие несколько физических Ethernet-адаптеров, что обычно делается для обеспечения более высокой пропускной способности или для обеспечения отказоустойчивых конфигураций. В настоящее время teaming поддерживает два режима балансировки пакетов между связанными интерфейсами: round-robin и active-backup. Для организации управления новым устройством подготовлена специальная библиотека libteam (https://github.com/jpirko/libteam), а также набор демонстрационных приложений;- Контрольная группа net_prio для управления сетевыми приоритетами (Network priority cgroup). Используя cgroup net_prio администратор теперь может динамически управлять приоритетом сетевого трафика, генерируемого различными приложениями. Традиционно, приложение может установить приоритет для своего трафика на этапе создания сокета через опцию SO_PRIORITY, но к сожалению это не всегда возможно. Cgroup позволяет (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6... администратору привязать процессы к группе, которая будет иметь иной приоритет д...
URL: https://lkml.org/lkml/2012/3/18/132
Новость: https://www.opennet.ru/opennews/art.shtml?num=33387
Появилась ли поддержка K10, в Processor Family Support?
K10 не настолько сильно отличается от K8, чтобы для них отдельную поддержку делать.
дык достаточно добавить пункт и запускать компилятор с правильным march
> дык достаточно добавить пункт и запускать компилятор с правильным marchПри том в gcc 4.7 подтянута реализация наборов команд и новых интелских процов, и новых амдшных, и поддержка C6x которая и в сабже - запилена. Там вообще по всем фронтам наступление. Я писаль ньюс про изменения в RC1 но его не заапрувнули, увы. Ща RC2 вышел уже. Скоро зарелизится, видимо, и будет довольно вкусной штукой.
Кстати, если определить подходящую переменную окружения, подхватит её make?
> Кстати, если определить подходящую переменную окружения, подхватит её make?А что есть "подходящая переменная"? Как это выглядит?
Феншуйные - CFLAGS, LDFLAGS, CC, CXX, MAKEFLAGS и т.п.http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...
> Феншуйные - CFLAGS, LDFLAGS, CC, CXX, MAKEFLAGS и т.п.Упс, что-то я эпически стормозил.
Конечно, да.
Почти в каждой новости о выходе ядра пишут, что удалено практически столько же строк, сколько и добавлено. Откуда рекорды по общему числу строк?
> Почти в каждой новости о выходе ядра пишут, что удалено практически столько
> же строк, сколько и добавлено. Откуда рекорды по общему числу строк?Почти столько же это если оценивать десятками миллионов строк, если присмотреться то добавлено 150 тыс новых строк. И так в каждой версии, за год примерно миллион набирается.
Добавлено 10753 тыс. строк кода, удалено - 10698 тыс. строк.
Итого, +57 тыс. за релиз. в год 5 релизов. (в 3.2 +56 тыс).
итого около 250 тыс...
Но за три года (17 релизов) набралось 5 миллионов. в среднем, +300 тыс за релиз, т.е. скачки "раздутия" неравномерны.
С уважением, анонимный "оналитик".
> Добавлено 10753 тыс. строк кода, удалено - 10698 тыс. строк.Ниже в той же новости
> размер исходного кода ядра превысил отметку в 15 млн строкТак что получается - больше 2/3 ядра за версию переписано?!!!
>> Добавлено 10753 тыс. строк кода, удалено - 10698 тыс. строк.
> Так что получается - больше 2/3 ядра за версию переписано?!!!Да ну??
""As of this writing, the 3.3 development cycle is at 3.3-rc6 and things are starting to look pretty stable. So it must be about time for our traditional summary of interesting statistics for the 3.3 kernel. It has been an active cycle, with some 10,350 changesets merged from just over 1,200 developers. Some 563,000 lines of code were added to the kernel, but 395,000 lines were removed, for a net growth of about 168,000 lines."" -- http://lwn.net/Articles/485058/
Спасибо, что обратили внимание, была ошибка в скрипте анализа патча. Правильные данные "добавлено 599 тыс. строк кода, удалено 432 тыс. строк".
Говорят в этой версии bug 12309 исправили. Кто проверял?
А что это и кого касается?
> А что это и кого касается?С добрым утром. https://bugzilla.kernel.org/show_bug.cgi?id=12309
> С добрым утром. https://bugzilla.kernel.org/show_bug.cgi?id=12309Кэп сообщает что этот баг лезет в сильно некоторых конфигах при сильно некоторых операциях, поэтому встречается лишь чуть чаще чем акулы посреди пустыни. По поводу чего и не прихлопнут местами. Одну причину которая потенциально могла вызывать такое поведение недавно пришибли, так что вперед - тестировать на проблемных конфигурациях, если они у вас есть.
О! Пойду тестировать. Где-то меня был старый конфиг ядра где эта проблема появлалась (надеюсь найду).// Если вдруг кому интересно: этот баг у меня был на сборке который основан на моем конфиге с нуля, и бага нет совсем если брать за основу конфиг слаки и кастомизировать под свои нужны. Да, я понимаю что можно диффнуть и методом исключения найти сочетания опции вызывающих проблему, но это требует много итерации компиляции ядра - что не совсем обосновано.
сильно некоторая операция к сведению КО
$ dd if=/dev/zero of=/tmp/test bs=1M count=1M
Был только один репорт об этом. Больше никто не подтвердил.
Его в каждой версии для половины машин исправляют, а для другой половины заново реализовывают.
> Его в каждой версии для половины машин исправляют, а для другой половины
> заново реализовывают.Странно, почему же тогда я его ни разу не видел?
>Странно, почему же тогда я его ни разу не видел?Скорее всего потому, что вы никогда не использовали линукс на декстопе более нескольких минут. Все кто использовал в той или иной форме его наблюдали. Спасают только Кон Коливас и pf.
Как пропатчить винду под ck/pf? А под линуксом — неа, не наблюдал :)
А о секурных дырах как обычно умолчали?
Сколько их исправлено...
а сколько их добавлено?
> а сколько их добавлено?Ой, да ладно вам, и так давно уже всем и все известно
Сюда нет смысла об этом что либо писать так как модеры красноглазики всеравно снесут такие каменты так как ни чего ни хотят принимать как факт
> всеравно снесут такие каменты так как ни чего ни хотят принимать как фактА что - факт? Если какой-то олух сомневается что в программах такого размера были, есть и будут есть баги - он дубина и должен идти работать дворником. Кстати обратите внимание: в этой формулировке вообще не фигурирует ни название софта, ни платформа. Это абсолютно универсальное свойство любого софта.
> нет смысла об этом что либо писать так как модеры красноглазики всеравно снесут такие каментыПравильно делают! Этот портал не место для обгаживания открытого ПО!
> Этот портал не место для обгаживания открытого ПО!Этот портал место для обгаживания закрытого ПО?
>> Этот портал не место для обгаживания открытого ПО!
> Этот портал место для обгаживания закрытого ПО?Ну поскольку проприерасы обычно сносят все нелестные комменты о своих поделках и багах в них дабы "бизнесу не мешало" - не вижу ничего такого чтобы мстительно припомнить им подобное на ресурсах где политика партии не привязана к бизнес-интересам конкретной конторки барыжащей софтом.
почитайте о предыдущих релизах последнее ядро 3.2.11. Примерно столько дыр и исправлено. сколько было убрано в 11 релизах, эти же патчи были приняты в ядро 3.3.
Очень глупый у вас вопрос - недальновидны вы и плоско мыслите.
а сколько их добавлено... ;)
Ладно, ладно.. вы мне скажите когда уже lz4 в btrfs появиться???
Вы уверены, что будет ощутимо лучше, чем с LZO?
Уверен ^^
> Вы уверены, что будет ощутимо лучше, чем с LZO?Как ни странно, на страничке проекта http://code.google.com/p/lz4/ есть относительно честные бенчи + ссылки на сторонние бечи.
Как правило
1) Оно жмет чуть быстрее LZO.
2) Декомпрессит оно временами аж в пару раз быстрее LZO.
3) Оно зачастую одновременно и быстрее и лучше жмет чем например гугловый snappy. Приветы гуглу, их обштопали.Итого: достаточно любопытный кандидат, хоть и написанный менее качественно чем LZO (парочка перцев с проблемами endianess, использнивание C99 во все поля без особых причин).
Возможно из-за этих проблем и не включили ещё. Если интересно, свяжитесь с Дэвидом и предложите ему помощь в подготовке патча.
Интересно. Но это еще не означает, что задействование lz4 повлияет на производительность btrfs. Если накладные расходы на сжатие с lzo уже несущественны, то дальнейшее улучшение производительности алгоритма сжатия может не дать ощутимого преимущества. Я не утверждаю, что это точно так, просто бенчмарки lz4 против lzo сами по себе не оправдывают переход на другой алгоритм.
> Интересно. Но это еще не означает, что задействование lz4 повлияет на производительность btrfs.На быстрых носителях типа SSD - вероятно может повлиять. Там очень быстрое чтение, так что декомпрессия в 2 раза быстрее может уже роялить в принципе.
> Если накладные расходы на сжатие с lzo уже несущественны,
Думается можно найти клинические случаи когда это не так. Вон SSD которым SATA мало - уже есть. Ну вон например монстры втыкаемые в PCI-E x16. Как вы думаете, с какой скоростью данные из 1 массива памяти в другой перетекают по скоростной шине? Думаете там несущественна разница в 2 раза? Не факт.
> то дальнейшее улучшение производительности алгоритма сжатия может не дать ощутимого преимущества.
Как бы потоки данных бывают разные.
> Я не утверждаю, что это точно так, просто бенчмарки lz4 против
> lzo сами по себе не оправдывают переход на другой алгоритм.Как бы это сказать? Если можно тратить меньше времени в некоей операции - лучше всего его тратить меньше. Файловая система может работать на куче
> на куче...разнотипных носителей.
Я же не утверждаю, что lz4 не нужен. Просто для обоснования его использования нужен несколько более сложный анализ в контексте ФС, а не сравнение круглых lzo и lz4 в вакууме.
> На быстрых носителях типа SSD - вероятно может повлиять.А много ли у вас несжатых данных в системе ? У меня в основном все сжато - архивы и медиаданные которые не жмутся простыми алгоритмами впринципе даже если они в виде RAW или PCM.
> А много ли у вас несжатых данных в системе ?Найдется, фигли.
- Все системные бинарники (библы, исполняемые файлы, конфиги, etc). Ускорить их подгрузку в пару раз - неплохая идея.
- Кэш браузера с мегатоннами великолепно жмущейся хтмлятины.
- Достаточно большие массивы данных, например выгруженных из OSM или несжатые битмапы для отсыла на принтер, manually generated, а потому - жмутся превосходно.
- У некоторых игр игровые ресурсы занимают дофига (сотни мб ... несколько Гб) и расположены в несжатом виде.> У меня в основном все сжато - архивы и медиаданные которые не жмутся
> простыми алгоритмами впринципе даже если они в виде RAW или PCM.RAW или PCM вполне может сжаться. Правда не так оптимально как специализированными алгоритмами, но - может.
> Найдется, фигли.Объем того что может сжаться в системе один рип hdtv перекроет, а если учесть объемы RAM современных компьютеров и что операции чтения/записи кешируются/буферизуются - пользы ноль от компрессии налету. Я к чему, неэффективно это сжатие нифига в современных реалиях - только процессор впустую нагружать.
> если учесть объемы RAM современных компьютеров и что операции чтения/записи кешируются/буферизуютсяА если присовокупить вращающиеся носители? И/или цену ssd?... Не останавливайтесь!
> - пользы ноль от компрессии налету.
> Объем того что может сжаться в системе один рип hdtv перекроет,Ага, посмотрю я как вы рипы на SSD свалите. Ценник за мег там довольно конский, но скорость то офигительна, а быстрое сжатие ее даже не испортит :)
> а если учесть объемы RAM современных компьютеров и что операции чтения/записи
> кешируются/буферизуются - пользы ноль от компрессии налету.Ага, кроме того что на ssd с системой и прочим в пару раз больше можно затолкать а если повезет то на не очень крутом и ынтырпрайзном - компрессия обгонит скорость записи и получится даже некий бонус к скорости записи. Не говоря уж о меньшем износе ssd т.к. меньше данных.
> Я к чему, неэффективно это сжатие нифига в современных реалиях - только
> процессор впустую нагружать.Линух работает на железках размерами от спичечного коробка до целого дома. Соотношение силенок проца и IO у них может существенно варьироваться. И в этом случае алгоритмы столь быстры что достигают существенного процента от скорости memcpy(). А вот дисковое io этим в современных реалиях обычно похвастаться не может.
> Ага, посмотрю я как вы рипы на SSD свалите. Ценник за мег там довольно конскийА зачем вы их тогда вообще покупаете если на нем даже ролик в приличном качестве записать - непозволительная роскошь :) лучше взять приличный диск с механикой на пару террабайт.
> Я не утверждаю, что это точно так, просто бенчмарки lz4 против
> lzo сами по себе не оправдывают переход на другой алгоритм.Там, вроде как, не переход на новый алгоритм, а добавление нового алгоритма. Т.е. хочешь LZ4 - используй его, не хочешь - пользуйся старыми алгоритмами сжатия (или вообще сжатие не используй).
Конечно. А ещё - там всего 1 байт отведён под тип сжатия, т. о. возможно 256 типов сжатия. Крис что-то говорил на этот счёт, мол, надо хорошенько подумать, прежде чем добавлять новый режим.
А можно поподробнее чем в 2012 году плох C99?
> А можно поподробнее чем в 2012 году плох C99?В случае именно алгоритма сжатия - тем что алгоритм этого класса потенциально может юзаться в очень разноплановых и разнокалиберных системах. Его декомпрессия не требует памяти (кроме буфера назначения куда пишется результат распаковки) вообще. Поэтому он может быть интересен даже в 8-битных тараканах для тетрисов и пультов (а чем плоха идея пожать огромные таблицы, суммарно не лезущие в памяти и подгружать их на лету например? Или там битмапы выдаваемые на экран?). Где такой авангардизм может икнуться тем что тамошний г-нокомпилер "так не умеет". Получится немного брейнфака на ровном месте с фиксингом. Хотя автор мог бы и сразу не раскладывать грабли.
Хм... Частично согласен, но если где-то такой дремучий компилятор и остальное, по идее не лучше. Закладываться на подобных уродцев... Брр. Да и для большинства эмбеда компиляторы на основе GCC, этото самый C99 сто лет как умеющего. А код на нём таки много читабельнее, одно объявление переменных по месту чего стоит.
> Хм... Частично согласен, но если где-то такой дремучий компилятор и остальное, по
> идее не лучше.Ну да, зато может стоить по цене грязи под ногами, например. Или быть частью уже существующей системы. Или являться встроенным вспомогательным ядром некоего вполне современного чипа, где это оставлено по причинам совместимости или нежелания лицензировать менее винтажное процовое ядро т.к. и это нормально работает, etc. Хотя копания в таком конечно следует избегать, но это возможно не для всех 100% людей и не в 100% случаев.
> Закладываться на подобных уродцев... Брр.
100% согласен, но например у чипов зачастую бывают какие-то мелкие и вспомогательные ядра, например на основе винтажноо 8051. Я что-то не уверен - а для '51 есть C99-совместимый компилер? Это не отменяет того что сие архаика, но эта архаика иногда попадается и в вполне современных чипах как некий вспомогательный элемент.
> Да и для большинства эмбеда компиляторы на основе GCC, этото самый C99 сто лет
> как умеющего.Ну да, с ним наиболее приятно работать. Вполне годный компилер, умеет дофига, кучу архитектур поддерживает, оперативно подхватывает свежеразработанные/доделанные. Но вот есть например хороший чипак. С кучей всего. И там допустим вспомогательный 8051 живет. Гнутый си на настолько хардкорных уродцев не рассчитан и генерить код для '51 не умеет вроде как.
> А код на нём таки много читабельнее, одно объявление переменных по месту чего стоит.
Иногда так читабельнее/удобнее, факт.
А чем оно лучше того же lzo?Мне интересно другое, когда запилят в grub поддержку сжатых btrfs разделов. Из-за этого приходится держать /boot на ext
А в чем проблема держать /boot на несжатом btrfs? Есть ли вообще смысл сжимать /boot?
А в чём проблема держать на сжатом? zfs умеет)
Grub поддерживает btrfs, но только без сжатия.
> Grub поддерживает btrfs, но только без сжатия.поддерживает сжатые, но только gzip. lzo - нет.
> А в чём проблема держать на сжатом? zfs умеет)ну и что?
какой смысл жать бинарное ядро, а тем более уже сжатый инитрд?
для того чтоб в случае повреждения данного раздела починить и распаковать его не было никакой возможности? или замедлить процесс стартовой загрузки и увеличить ресурсоемкость(для распаковки нужен как шустрый процессор так и доп. ОЗУ) запуска ядра? и это все для того чтоб выиграть 10проц раздела, которому если выделить и 200Мб, то можно закидаться ядрами по самое нихачу... )))бут-раздел должен быть на максимально доступной по формату партиции, чтоб в случае повреждения можно было с ней сделать все что угодно без особых танцев...
>какой смысл жать бинарное ядро, а тем более уже сжатый инитрд?А тем более сжатое бинарное ядро.
lz4 почти в 3 раза быстрее распаковывает сжатые данные
> lz4 почти в 3 раза быстрее распаковывает сжатые данныеЭто имеет значение, если доля использования ЦП существующим алгоритмом сжатия (lzo) еще существенна относительно нагрузки, создаваемой драйвером ФС в целом. Так ли это?
Она более чем существенна. Переношу сейчас систему на сжатый btrfs. Загрузка процессора близка к полной. Правда это кора дуба экономичная, но...
Сжатие как ни как - очень ресурсоемкий процесс и надо бы для fs найти золотую середину между эффективностью и скоростью (где-то какой-то доп параметр задать?). Я же пока не разобрался и просто монтирую с ключем compress.
> Я же пока не разобрался и просто монтирую с ключем compress.Ну если у вас zlib юзается - то он вообще тормозной и так и сяк. По сравнению с lzo/lz4/snappy и прочими.
> Она более чем существенна. Переношу сейчас систему на сжатый btrfs. Загрузка процессора
> близка к полной. Правда это кора дуба экономичная, но...
> Сжатие как ни как - очень ресурсоемкий процесс и надо бы для
> fs найти золотую середину между эффективностью и скоростью (где-то какой-то доп
> параметр задать?). Я же пока не разобрался и просто монтирую с
> ключем compress.Там, насколько я знаю, выбор между эффективностью и скоростью достигается за счет выбора алгоритма: compress=gzip — медленно, но сжатие больше, compress=lzo — быстро, но степень сжатия меньше. Выбор по умолчанию может зависеть от версии.
Еще вместо compress можно сказать force-compress. С force-compress сжатие применяется ко всем файлам, с compress сжатие отключается для файлов, которые сжать не удалось.
> существенна относительно нагрузки, создаваемой драйвером ФС в целом. Так ли это?А вы купите SSD втыкаемый в PCI-E x16 и расскажите как оно там на таких скоростях. А то я конечно понимаю что для некоторых тормозной ноутбучный винч предел мечтаний, но btrfs для систем разного калибра делается.
Ну и пусть себе на ext сидит. Эти несколько файлов размером в единицы (максимум - десятки) мегабайт можно держать на чём угодно.
> А чем оно лучше того же lzo?Шустрее!
> Мне интересно другое, когда запилят в grub поддержку сжатых btrfs разделов.
В btrfs уже запилили индивидуальное сжатие или несжатие конкретных файлов, может быть, достаточно отключить сжатие для файлов из /boot? :)
> А чем оно лучше того же lzo?Быстрее.
> Мне интересно другое, когда запилят в grub поддержку сжатых btrfs разделов. Из-за
> этого приходится держать /boot на ext
>вы мне скажите когда уже lz4 в btrfs появиться???Фороникс подаст:
The LZ4 compression support [censored] will land in the Linux 3.4 kernel.
http://www.phoronix.com/scan.php?page=news_item&px=MTA1OTQНу, типа месяца ч-з три. Устроит?
Когда сделали fuse я обрадовался: правильная тенденция. Сделать интерфейсы для остальных подсистем в юзерспейс, повыносить рюшечки из ядра, и оставить только необходимый функционал. Пора ведь уже повзрослеть. Я не говорю о микроядре: это вызовет инфаркт у создателя. Но ведь объем неуклонно растет, неужели никого это не напрягает?
Почему кого-то это должно напрягать?
Линуса напрягает же
И правильно напрягает
Моё впечатление от fuse - медленно и неэкономично
> Моё впечатление от fuse - медленно и неэкономичноМое впечатление: вашумать, оно умудряется упереться в CPU а не IO! Разумеется сливая по скорости ядерной реализации в разы.
>> Моё впечатление от fuse - медленно и неэкономично
> Мое впечатление: вашумать, оно умудряется упереться в CPU а не IO! Разумеется
> сливая по скорости ядерной реализации в разы.дану.
> дану.Что - дану? Берем ntfs реализованный в FUSE и тихо худеем как оно ненапряжно упирается в CPU а не диск на ровном месте. Это на довольно мощной машине, btw. Та же конторка почему-то делает модуль ядра и ... продает его на коммерческой основе производителям девайсов. Предлагая повышенную в несколько раз скорость как фичу, что как бы намекает... :D
ntfs-3g не показатель.
> ntfs-3g не показатель."Если факты не подтверждают теорию, от них надо избавиться!" (законы Мерфи). Так, да? :)
>Предлагая повышенную в несколько раз скорость как фичу, что как бы намекает... :DНа то, что конторке выгодно, чтобы их FUSE драйвер тупил.
> На то, что конторке выгодно, чтобы их FUSE драйвер тупил.Так в случае fuse это автоматически обеспечивается лютым переключением контекстов между кернелом и юзермодом крупным оптом. Это настолько фундаментально и никак не лечится кроме как перепиской в нормальном виде, как модуль ядра, что эти парни могут быть способны за свой бизнес и не бояться особо всяких зело вумных оптимизаторов, которые в 2 коммита сделают их деятельность нецелесообразной :)
Вот тут аноним, ты дал ясно понять что не разбираешься в сути вопроса. Именно об этом: еще в дремучие 90ые разработчики мироядра Mach пришли к выводу что системы на микроядре нецелесообразны из-за неприемлимых накладных расходов появляющихся из-за двух переключении контекстов исплонения (+ время на его аутентификацию) для одного сообщения. Вы действительно хотите такую систему? По мне так модульное ядро (текущее состояние дел в Linux) оптимальный вариант. Ну а в системы где скорость не столь критичная (банкоматы, терминалы оплаты и пр.) можно и микроядра натолкать (хотя о чем это я говорю когда в банкоматах стоят пиратские XP xD).
> и пр.) можно и микроядра натолкать (хотя о чем это я
> говорю когда в банкоматах стоят пиратские XP xD).Кто тебе такую чушь сказал? там стоит вполне себе лицензионный ембедед едишн.
Кто тебе такую чушь сказал?Ой, да ладно, так уж и чушь. Поспрашивай ребят которые с этими банкоматами бодаются (вне МКАД'а) - они тебе и расскажут что и как есть на самом деле (от них и информация).
> И правильно напрягает
> Моё впечатление от fuse - медленно и неэкономичноК тому же небезопасно. Юзер добавляется в группу fuse и может монтировать все, что ему взбредет, как ведь?
Меня в случае таких вопросов учили спрашивать: "Кто принимает решения?" Линус Торвальдс. Он уже обозначил что в курсе этой проблемы, но делать ничего не собирается. Значит вопрос закрыт.
> Значит вопрос закрыт.И это к лучшему, ибо вменяемый руководитель проекта - лучше тысяч индусни, где никто ни за что не отвечает. Валите и делайте свои ядра, как вам там удобно, а мы посмотрим как у вас получится и будет ли лучше. Если это будет лучше и на условиях не хуже (свои EULA засуньте куда-нибудь подальше) - приходите и мы с удовольствием будем пользовать ваши ядра везде где дотянемся.
А где в ваших словах то самое мериократическое сообщество?
> А где в ваших словах то самое мериократическое сообщество?В моих словах полное выражение вашей свободы. Свободы заткнуться и сделать лучше, например. Припереться из своего майкрософта и указывать другим что делать - не комильфо, они и без ваших соплей разберутся. Хотите указывать открытому проекту? Окей, станьте уважаемым кучей народа лидером, сколотите эффективную команду и сделайте лучше. Тонны уважения обеспечены. И даже с голода помереть такой нужной персоне врядли дадут.
Харашо сказал!
Где-то рядом. Никто же ж не виноват что твой парсер слабоват ж ? ж ж ж ..
>Пора ведь уже повзрослеть.Действительно. Чего так комплексовать об размере-то?
> Когда сделали fuse я обрадовался: правильная тенденция.Да, конечно. А апофеозом наверное является реализация ФС на питоне. Правда пока оно там файло запишет - уснуть можно будет. Вообще, вы видели с какой скоростью работают ФС в ядре и с какой - FUSE. Ну вот туда же можете и с микроядрами валить.
> Но ведь объем неуклонно растет, неужели никого это не напрягает?
Ну так он сильнее всего растет в драйверах оборудования и аппаратной специфике платформ, если вы не заметили. Как вы понимаете, в окончательно скомпиленном ядре обитает только ограниченный субсет этого кода.
> Да, конечно. А апофеозом наверное является реализация ФС на питоне. Правда пока оно там файло запишет - уснуть можно будет. Вообще, вы видели с какой скоростью работают ФС в ядре и с какой - FUSE. Ну вот туда же можете и с микроядрами валить.Если не брать во внимание MMAP IO то FUSE дает просадку не более чем в 2 раза по сравнению с чисто ядерной реализацией. на MD операциях - это более заметно - но тоже не все так катастрофично как вы пытаетесь показать.
Зато предложу вам запихать sshfs в ядро..
> Если не брать во внимание MMAP IO то FUSE дает просадку не более чем в 2 раза
> по сравнению с чисто ядерной реализацией.Кто и как это замерял? Если например взять FUSE драйвер NTFS - это просто эталонный тормоз, выбросив который я поднял скорость дисков в пару раз и разгрузил проц во многие разы.
> на MD операциях - это более заметно - но тоже не
> все так катастрофично как вы пытаетесь показать.А я вот поюзав так и сяк пришел к выводу что шло бы оно куда подальше, по крайней мере в качестве дисковый файловых систем общего назначения. Для каких-то спец-применений типа того что вы озвучили - сойдет, но ФС общего назнаения на этом получаются более чем унылые по параметрам.
> Зато предложу вам запихать sshfs в ядро..
А там о скорости вообще спич не идет - на быстром линке шифрование и так проц в полку выжрет.
>Кто и как это замерял? Если например взять FUSE драйвер NTFS - это просто эталонный тормоз, выбросив который я поднял скорость дисков в пару раз и разгрузил проц во многие разыА вот тут можно поподробней? Что использовалось вместо и т.д.? Задача — максимально быстрые чтение-запись для флешек с ntfs.
paragon ntfs express
Понятно. Разница в скорости с ntfs-3g впечатляет, но проприетарная штука, увы. к тому же надо пересобирать под конкретное ядро. Боюсь, весь выигрыш от скорости копирования съестся временными затратами на пересборку при обновлении ядра — не так уж много я ntfs использую. Но всё равно спасибо.
> Понятно. Разница в скорости с ntfs-3g впечатляет, но проприетарная штука, увы.Увы. Однако разница достаточна для того чтобы контора которая сие делает могла продавать нормальную реализацию как фичу, т.к. в разы быстрее против фузевого тормозилова.
Оно ещё, судя по всему, только для ядер 2.6.38 и ниже. Т.е. как часто в таких случаях бывает, поддержка отстаёт на пару-тройку версий.
> Оно ещё, судя по всему, только для ядер 2.6.38 и ниже.То был другой аноним. У меня к счастью нет NTFS дисков на данный момент и проблема отпала как класс. А вот заявлять что FUSE реализация работает быстро и не грузит проц по черному - наглейшее, беспардонное вранье. Достаточно сравить с ядерными реализациями и/или иными ФС в ядре.
Не скажу за все fuse-реализации, но вот конкретно ntfs-3g при записи большого количества мелких файлов на флешку тормозит адски.
> количества мелких файлов на флешку тормозит адски.При записи на винч оно тоже адски тормозит и временами грузит 1 ядро CPU под завязку. Ни одна ядерная реализация ФС такой хардкорной жести себе не позволяет.
> весь выигрыш от скорости копирования съестся временными затратами на пересборку при обновлении ядраГде мой валидол? Бывает же, что люди компилят ядра 24/7/365 и львиную долю этого процесса занимает один драйвер...
> Где мой валидол? Бывает же, что люди компилят ядра 24/7/365...и делают это зачем-то на NTFS! Эти мсье знают толк.
Я за свою жизнь собрал ровно одно linux-ядро и то интереса ради. Году так в 2002-2003. Может это у тупых виндотроллей, что знают о линуксе по цитатам на башорге, такое странное хобби — ядра собирать?
Не загоняйся. Не знаю таких кто собирает ядра чтобы собирать ядра, но знаю тех кто сбирает ядра исключительно по необходимости (сам такой же).
Где почитать про teaming?Когда можно брать в продакшн?
в изначальном письме с патчем есть описание
http://lwn.net/Articles/467280/
я так понял в 3.3 xfs improved? есть тесты какие-нибудь уже на эту тему?
Да, интересный вопрос. У меня дома она разные ext таки вытеснила.
старый pohmelfs выкинули, новый не добавили.
>При этом, созданный образ bzImage является универсальным и кроме поддержки EFI >может использоваться без изменений и с классическими загрузчиками, вызываемыми >из BIOS;KISS!
> KISS!Вот они, хакеры-системщики во всей красе. У них и образ флешки образом сидюка является, и образ понимаемый BIOSом понимается и EFI. Хотя ни то ни другое изначально ни разу не задумывалось :)
> Поддержка загрузки с использованием EFI (Extensible Firmware Interface). В состав ядра включен набор компонентов, необходимых для загрузки и запуска образа ядра (x86 bzImage) непосредственно прошивкой EFI.Отлично.
И каждый раз после выхода ядра страничка на kernelnewbies либо жутко лагает, либо вообще лежит. Эх. ikiwiki со статическими страницами по ним плачет..
Иоваит, иоваит то пофиксили?!
> Иоваит, иоваит то пофиксили?!Попробуйте прочитать новость. Пофиксилось ли оно лично у вас - так возьмите и ПРОВЕРЬТЕ. За вас на вашей конфигурации этого никто не сделает.
Ну так протестируйте и сюда отпишитесь: https://bugzilla.kernel.org/show_bug.cgi?id=12309
Если-бы имел возможность протестировать сейчас - не спрашивал бы. Спросил у тех кто уже попробовал :)
Лично у меня оно нигде и раньше не проявлялось, увы.
> Если-бы имел возможность протестировать сейчас - не спрашивал бы.А у меня и раньше не было проблем. Наивно думать что один баг который лезет лично у вас - тиранит все человечество. Тиранил бы он все человечество - давно б прихлопнули. Стал бы Торвальдс терпеть баг у себя под носом мещающий ему жать, агащаз.
не говорите за себя, залезте в гугл 12309. Сколько людей из за него страдают. И если он у вас не проявился, то радуйтесь, а не мусольте глаза другим...
так на каком железе она у вас проявляется?
> не говорите за себя, залезте в гугл 12309.А зачем гугл - есть багзилла. И да, в 3.3 явно починен один баг который потенциально мог вызывать нечто подобное в определенных ситуациях граничащих с хорошим детективом но вполне возможных. Так идите и проверьте, чтоли.
> Сколько людей из за него страдают. И если он у вас не проявился, то радуйтесь,
> а не мусольте глаза другим...Это лучше вы идите и посмотрите, помог ли вам фикс, вместо того чтобы засирать форумы бесполезным нытьем.
Хинт: разработчики ядра не особо читают форумы. А вот багтрекеры например - очень даже.
>Новая реализация механизма изменения размера ФС Ext4.теперь стало опасно менять размер?
уменьшать смонтированную фс оно научилось?
>Добавлено 10753 тыс. строк кода, удалено - 10698 тыс. строк.Не верю! 10 млн. строк. Они там что, 2/3 ядра переписали?
>Поддержка перестроения данных (restriping) между различными RAID-уровнями (т.е. можно перейти от одного типа RAID на другой). Поддержка новой возможности реализована в ветке "parser" инструментария btrfs-progs;Это как понимать?
На brtfs можно будет из 4-ёх винтов аппаратного RAID 0 добавить 5-ый винт в кучу или выкинуть один винт или вообще на RAID5 перейти не теряя данных?
Звучит как сказка, но что-то сомневаюсь что я правильно это понял :)
Нет, в btrfs есть программный рейд на уровне ФС, когда например в RAID 0 между дисками распределяются не блоки, а файлы.
Это значит, что есть у вас есть фс, расположенная на одном диске, то вы можете просто подключить второй диск и на лету превратить вашу фс в, например, raid1. Потом подключить ещё два и, так же на лету, сделать raid10. Ну и т. п.
Понял! Спасибо:)
что будет в следующем релизе? (когда он будет?). Не было ли в этот раз появления регрессий? (либо устранения старых). И если написано, что есть существенные улучшения в BTRFS, то стоит ли теперь при новых инсталляциях форматировать диск под нее а не другие?
> что будет в следующем релизе? (когда он будет?).Варианты для нетерпеливых:
- Мониторите профильные гиты и их ченжлоги.
- Читать списки рассылки и профильные ресурсы
- На форониксе тамошний новостеписатель публикует наиболее интересные и заметные изменения как новости.Если это кажется слишком сложным - ну тогда ждите свежего выпуска новостей.
> Не было ли в этот раз появления регрессий?
А об этом мы узнаем в следующем выпуске новостей :). Почему-то мир так странно устроен что сначала при разработке софта делают баги, а только потом их обнаруживают.
> (либо устранения старых).
Попробуйте прочитать текст новости?! Если этого мало - к вашим услугам логи коммитов git, там хоть обчитайтесь.
> И если написано, что есть существенные улучшения в BTRFS, то стоит ли теперь
> при новых инсталляциях форматировать диск под нее а не другие?На _ващем_ месте я бы ждал зеленого свистка от разработчиков с официальным объявлением стабильности. Ну так, глядя на уровень вопросов. Если что-то пойдет не так - вы с такими "умными" вопросами врядли сможете починить проблемный диск. Поэтому лично я бы на вашем месте предоставил возможность другим проверить насколько там нет багов. А вот когда станет понятно что ничего серьезного не осталось совсем - тогда уже и пользовать вовсю.
btrfs пока использовать стоит ровно так, как положено использовать любой другой код с меткой experimental.
> Добавлено 10753 тыс. строк кода, удалено - 10698 тыс. строк.Это аж 10.7 млн строк кода? Получается каждый разработчик написал в среднем по 10000 строк кода? Или все же 10.7 тысяч строк кода?
Туплю :) Фантастические цифры... Это же вероятность ошибок новых очень велика.
Все это хорошо конечно, вот только одно жаль не кому почти поддерживать такую замечательную файловую систему в Reiser4. А жаль(( Ну хоть на 2.6.38 сиди да и все
у этой ФС есть киллер(в прямом и переносном смысле :D )-фичи? ^_^
ее нет в ядре, боюсь что это минус - и какие ее плюсы перевесят этот минус? минусищще?
Reiser4 была в своё время ОЧЕНЬ перспективной ФС, но по ряду причин её подзабросили. Сейчас все пилят Btrfs, хотя она в данный момент очень небыстра.
> очень небыстра.Ага, забенчите рейзер с включенным tail packing'ом и доложите о скорости :). Btrfs ВНЕЗАПНО реализует чем-то похожую технику когда мелкие файлы хранят прямо в дереве, не теряя место на целый блок ФС, только у них это ускоряет работу ФС а не тормозит почему-то.
Неплохо, всё лучше и лучше.
Ну где нытики, которые обещали нам фрагментацию и развал ядра? Наработки Android возвращаются в ядро, как и предсказывалось. :)
> Ну где нытики, которые обещали нам фрагментацию и развал ядра?Да не получится там никакой фрагментации, центр тяготения есть и "законы физики" в лицензии правильно поюзаны, в отличие от тех самых нытиков, у которых ошметки по всей галактике разлетаются :)
Все здесь - http://www.linux.org.ru/news/opensource/7536825Если уж сами разработчики говорят, что что-то не так. То красноглазым пора уж поверить своим фюрерам.
> уж поверить своим фюрерам.Это у вас - фюреры. А тут у каждого своя бошка на плечах и никто никому ничего не должен и строиться в строй по свистку кого либо - вовсе не обязан. Однако если много людей будет заинтересовано в решении задачи в именно таком виде - они объединятся и справятся. А если так не произойдет - ну ой, значит участники процессов решили что им так не по вкусу и не отражает их интересы и хотелки.
> Если уж сами разработчики говорят, что что-то не так. То красноглазым пора
> уж поверить своим фюрерам.Да, лан! Троль из КрасноШапки рассказывает, "Как нам обустроить Линакс Аппс Маркет". Пусть Нокиасофты и Эплоракелы трясутся, нам-то что....
Необходимость принудительного использования безопасной "песочницы" для запуска приложений как на уровне пользователя, так и на уровне ядра. Сегодня установка нового пакета из репозитория - это компромисс и выбор из серии "все или ничего" в плане общей безопасности системы. Пользователи должны быть свободны в своём желании получать и запускать даже непроверенный код.
Вот пущай для начала напишет такую песочницу!!!
> Вот пущай для начала напишет такую песочницу!!!LXC? Или для особо злых KVM? В принципе оно уже есть.
> LXC? Или для особо злых KVM? В принципе оно уже есть.Средства контейнерезации и виртуализации не являются инструментами безопасности. Не совсем и не до конца во всяком. //Ваш Капитан.
"В основное дерево ядра из ветки staging перенесён драйвер gma500"Т.е. на Asus T91 будет работать без бубна? Насколько этот драйвер шустрый, что в нем реализовано? Пришлось винду ставить на нетбуке из-за этой видеокарты )