Линус Торвальдс представил (https://lkml.org/lkml/2012/12/10/688) релиз ядра Linux 3.7 (http://kernel.org/). В новой версии представлена большая порция существенных изменений, связанных с архитектурой ARM: возможность формирования многоплатформенных ARM-сборок, поддержка архитектуры AArch64 (ARM64), адаптация Xen для работы на процессорах ARM Cortex A15. Из других улучшений можно отметить реализацию пространства имён для идентификаторов пользователей, возможность проверки цифровой подписи при загрузке модулей ядра, использование инструкций SMAP для защиты от эксплуатации уязвимостей в ядре, поддержку протоколов SMB2.1 и VXLAN, реализацию GRE и NAT для IPv6, поддержку режима TFO на стороне сервера.
В новую версию принято 10409 исправлений от более чем 1200 разработчиков, размер патча - 95 Мб (изменения затронули 15886 файлов, добавлено 1570793 строк кода, удалено 1246965 строк). В связи с изменением структуры размещения и переработкой иерархии дириекторий некоторых частей ядра, размер нынешнего патча более чем в два раза больше по сравнению с прошлыми выпусками. Около 33% всех представленных в 3.7 изменений связаны с драйверами устройств, примерно 23% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 6% связано с сетевым стеком, 3% - файловыми системами и 3% c внутренними подсистемами ядра.
Наиболее интересные новшества (http://kernelnewbies.org/Linux_3.7) ядра 3.7:-
Аппаратные архитектуры- Поддержка (https://lkml.org/lkml/2012/10/1/313) 64-разрядной архитектуры AArch64 (ARM64), реализованной в процессорах, поддерживающих набор команд ARMv8. 64-рязрядная архитектура AArch64 включает (http://www.opennet.ru/opennews/art.shtml?num=34285) в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON, такими как инструкции для ускорения работы алгоритмов шифрования AES и SHA-1/SHA-256. Реализация AArch64 для Linux поддерживает расширенную 39-разрядную адресацию памяти для ядра и пользовательского уровня и предоставляет режим совместимости, позволяющий выполнять 32-битные программы, собранные для архитектуры ARMv7 (ARM EABI). В настоящее время устройства на базе ARMv8 пока находятся на стадии тестирования прототипов, поступление в продажу первых ARMv8-систем ожидается в следующем году;
- Унификация (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...) кода поддержки архитектуры ARM и обеспечение возможности формирования многоплатформенных ARM-сборок. Если ранее требовалось собирать отдельный вариант ядра для каждого типа SoC, то начиная с выпуска 3.7 появится возможность собрать одно ядро, которое будет содержать поддержку различных ARM-платформ. Унифицированная сборка ядра 3.7 сможет работать на платформах Calxeda Higbank (серверы HP Moonshot), Versatile Express (эталонная плата, поддерживается эмулятором QEMU), Marvell ARMADA (от мини-серверов до телеприставок), Altera SoC FPGA и Picohip picoXcell (мини-базовые станции для офисов). В будущих выпусках ядра число поддерживаемых платформ будет расширено. Указанное нововведение существенно упростит жизнь разработчикам дистрибутивов для ARM-систем, которым теперь не придётся формировать отдельный загрузочный образ для каждой ARM-платформы.
-
Виртуализация и безопасность- Поддержка (http://blog.xen.org/index.php/2012/10/08/xen-arm-in-linux/) механизмов виртуализации Xen для систем на базе процессоров ARM Cortex A15. Таким образом Xen стал первым гипервизором, поддерживаемым в Linux на платформе ARM. Представленный для интеграции в ядро код основан на использовании аппаратных расширений для обеспечения виртуализации, поддерживаемых архитектурой ARMv7. Особенностью реализации Xen для ARMv7 является отсутствие разделения в поддержке запуска гостевых систем в режиме паравиртуализации (PV) и аппаратной виртуализации (HVM). Вместо этого используется один комбинированный режим запуска гостевых систем, напоминающий запуск PV поверх HVM без необходимости эмуляции оборудования при помощи Qemu. Гостевые системы при этом всегда запускаются в режиме полной виртуализации, но для доступа к сетевым и блочным устройствам должны использовать специальные паравиртуальные драйверы (т.е. для гостевых окружений не требуется модификация ядра системы, но необходимо наличие нескольких драйверов).
- Добавлена (https://lwn.net/Articles/491310/) рабочая реализация пространств имён для идентификаторов пользователей (user namespaces). Указанная возможность позволяет сформировать в контейнерах собственные наборы идентификаторов групп и пользователей, а также связанные с ними привилегии (например, в каждом контейнере может быть свой root);
- Поддержка (https://github.com/mirrors/linux-2.6/commit/15385dfe7e0fa686...) набора инструкций SMAP (Supervisor Mode Access Prevention), реализованного в процессорах Intel на базе микроархитектуры Haswell. Задействование SMAP в ядре позволяет (http://forums.grsecurity.net/viewtopic.php?f=7&t=3046) блокировать доступ к данным в пространстве пользователя из привилегированного кода, выполняемого в пространстве ядра (по аналогии с тем, как добавленная в ядре 3.0 поддержка SMEP не позволяет переходить из режима ядра к выполнению кода, находящегося в пользовательских областях). При обеспечении оборудованием поддержки инструкций SMAP, представленные средства защиты будут включаться автоматически, что существенно усложнит эксплуатацию уязвимостей в ядре, вызванных такими ошибками, как разыменование NULL-указателя;
- Поддержка (https://lwn.net/Articles/470906/) загрузки модулей ядра с проверкой их корректности по цифровой подписи. Указанная возможность разработана в рамках проекта по обеспечению поддержки загрузки верифицированного ядра Linux на системах с включенным режимом UEFI Secure Boot. При активации данной опции, ядро будет отвергать загрузку любых модулей для которых нет корректной цифровой подписи. Поддерживается и отладочный режим, при котором выполняется проверка, но она не влияет на загрузку модулей и информирует о проблемах через лог. При сборке ядра, при наличии открытого и публичного ключей процесс создания подписей для собираемых модулей выполняется автоматически, а проверочный ключ интегрируется в файл crypto/signature/key.h. Отмечается, что генерация цифровых подписей немного замедляет процесс сборки;- В соответствии с пожеланиями разработчиков systemd, расширенные атрибуты для управляющих групп (control groups) могут задаваться через создание иерархии директорий. При использовании неиерархических групп управления во вложенных элементах иерархических групп будет выдаваться ошибка;
-
Дисковая подсистема, ввод/вывод и файловые системы- В файловую систему Btrfs добавлена (http://www.phoronix.com/scan.php?page=news_item&px=MTIwMzI) поддержка "hole punching", технологии при которой часть файла можно пометить как более неиспользуемую. Это позволяет файловой системе и носителям (например, накопителям SSD) заранее освобождать неактуальные неиспользуемые блоки в середине файла. Кроме того, в новой версии ядра сильно ускорена работа системного вызова fsync() на btrfs;
- В реализации файловой системы CIFS обеспечена поддержка протокола SMB2.1. Статус поддержки SMB2 на уровне ядра переведен из разряда "поломанный" в "экпериментальный";
- Добавление (http://lwn.net/Articles/488906/) модуля IMA (Integrity Measurement Architecture) для обеспечения хранения и проверки базы хэшей для проверки целостности файлов и связанных с ними метаданных. Данные для контроля целостности сохраняются как атрибуты xattr;
- В реализацию программных RAID (MD RAID) и файловой системы JFS добавлена поддержка команды TRIM (discard), которая позволит увеличить производительность при работе с SSD-накопителями и повысить их срок службы;
- Перевод реализации NFS 4.1 в разр...URL: https://lkml.org/lkml/2012/12/10/688
Новость: http://www.opennet.ru/opennews/art.shtml?num=35554
Кто нибудь в курсе когда андроид сможет ванильные ядра использовать, а не свои патченные? Чего в ванильном гуглу не хватает?
Посмотри патчи от гугла, стане понятно чего не хватает.
Как минимум патчей cgroups, устройств ввода, netfilter. Хотя и так запустится, но не так как хотелось бы.
Вливание Andoid-патчей в апстрим завершилось в какой-то из недавних предыдущих версий ядра. Так что по идее уже должен мочь.
> Вливание Andoid-патчей в апстрим завершилосьТолько одной из порций. Это еще не все вроде.
>Чего в ванильном гуглу не хватает?То ли time-а to market, то ли контроля, то ли проприертарно-закутковоых игрищ с "вендорами" в стиле unix-death... Не думаю, что тебе здесь на это ответит кто-то из Гугля.
> Изя он УЖЕ использует линуксовые. Хватит завидовать.Это уже даже до слоупоков дошло. И только бсдшниик изя все тормозит.
На фиг не нужны андроидные костыли в ванильном ядре.
> На фиг не нужны андроидные костыли в ванильном ядре.Но хочется же апстримовое ядро на андроидо-фоне. //Да, бачили очи, знаю.
> На фиг не нужны андроидные костыли в ванильном ядре.Некоторые из - пригодятся, ибо нужны мобильным платформам.
В основном, проблемы в дровах. Поэтому одно ядро под одно устройство (пока)
Пока производители не откроют дрова или хотябы не запатчат их в ядро, универсальых дистров мы не увидим.
> В основном, проблемы в дровах. Поэтому одно ядро под одно устройство (пока)Нет, проблема в ARM-е. У них тупо _нет_ "единого образа". Device tree не запилили ещё, загрузчики везде разные, даже наборы команд "усиленно совершенствуют".
> Пока производители не
Ну, с этими тоже проблемы.
> даже наборы команд "усиленно совершенствуют".Интел и амд этим тоже не брезгуют.
По поводу Btrfs отмечу, что на их официальной вики было анонсировано больше изменений: https://btrfs.wiki.kernel.org/index.php/Main_Page#News
* fsync speedups
* removed limitation of number of hardlinks in a single directory
* file hole punching
* per-file NOCOW
* fixes to send/receiveА Матиас Экерман (Matthias Eckermann), старший управляющий выпусками в SUSE, выразил мнение, что новая файловая система уже готова для повсеместного (в т.ч. на производственных системах) применения. Она официально поддерживается в SUSE начиная с версии 11SP2. Пользователям предлагается использовать btrfs для корневого раздела.
Пруф: http://www.linux.com/news/enterprise/systems-management/6772...Может быть и в Android войдёт, как уже было с Ext4.
http://www.h-online.com/open/features/Kernel-Log-Coming-in-3...
Вот ещё с H-online обзор изменений файловой подсистемы.
> Вот ещё с H-online обзор изменений файловой подсистемы.Малость допатчил новость. Могли бы и сами дописать - вон там под ней чудная кнопка "редактировать". Доуступно всем и каждому.
> выразил мнение, что новая файловая система уже готова для повсеместного (в т.ч. на производственных системах) применения.это он про свои компьютеры ?
> Она официально поддерживается в SUSE начиная с версии 11SP2.
так вот почему у моих друзей OpenSUSE после нескольких включений - выключений она пеерставала грузится ))))
> Пользователям предлагается использовать btrfs для корневого раздела.
юзеры просто ничего не знают что это за ФС
> так вот почему у моих друзей OpenSUSE после нескольких включений - выключений она пеерставала грузится ))))Не поэтому, а потому что руки кривые. По умолчанию используется ext4.
> Не поэтому, а потому что руки кривые.руки разработчиков ?
разрабы врут и не краснеют
то что вы там врёте — это да, а вот что вы разработчики — это уже нет.
> то что вы там врёте — это да, а вот что вы
> разработчики — это уже нет.ага, установить скайп и оперу и ОС перестала грузится, так это руки кривые да ?
а то что сам Томас писал, про пакеты в репах и надо их более подробно потестить, так это уже забыли ?
и я уже вру ?
>ага, установить скайп и оперу и ОС перестала грузится, так это руки кривые да ?во-о-от.
два раза выйти в инет через ие чревато.
нужно только одни раз. на мозила.орг
>> Она официально поддерживается в SUSE начиная с версии 11SP2.
>так вот почему у моих друзей OpenSUSE после нескольких включений - выключений она пеерставала грузится ))))все твои друзья не могут быть не евангилистами, как и ты.
поэтому да, OpenSUSE у твоих «друзей» перестала грузиться именно из-за этого… или из-за молотка, которым евангилисты бьют системник, если в нём какой-нибудь линух.>> Пользователям предлагается использовать btrfs для корневого раздела.
>юзеры просто ничего не знают что это за ФСконечно. ваши юзеры только в реестре копаться умеют.
> конечно. ваши юзеры только в реестре копаться умеют.
они не мои, а с чего берут что они мои )))
я не такой дурак что бы под гарантию подписыватся )))
вот не надо сюда мс еула копипастить.
все местные итак в курсе.
свободное место может закончилось?
с btrfs за ним глаз да глаз нужен.
раньше с ext4 10Gb за глаза хватало для корневого раздела (почти половина раздела пустовала), теперь с btrfs уже несколько раз место заканчивалось и система не загружалась.
приходится удалять снапшоты, а то и балансировку файловой системы проводить.
очень грустно.
> приходится удалять снапшоты,Внезапно, хранение нескольких состояний ФС оказывается жрет место. А вы думали что разные состояния и отличия от них хранятся в астрале, а не на диске? :)
Грубо говоря, если вы сделали постоянный снапшот, ФС будет записывать все изменения после него. Чем больше изменений - тем больше места сожрется. Это не только BTRFS так себя ведет, если что. Любая CoW структура обладает теми эе свойствами. Например, диски виртуалок поддерживающие снапшоты - распухают если снапшот был далеко и после этого было много записано. Ну и так далее.
Спасибо, открыли мне Америку!
Я вообще-то писал о том, что теперь пользователю придется более внимательно следить за свободным местом на разделе и проводить выше упомянутые мной операции.
> Я вообще-то писал о том, что теперь пользователю придется более внимательно следить
> за свободным местом на разделе и проводить выше упомянутые мной операции.Ну да, управлять автомобилем сложнее чем кибиткой. Приходится внимательно следить за дорожной разметкой, знаками и вообще ситуацией на дороге. Отсюда не следует что авто хуже кибиток. Просто к водителям чуть больше требований. Кому не нравится - юзайте кибитки и не юзайте автомобильные дороги, хренли.
О, пржевальский снова с нами.
> так вот почему у моих друзей OpenSUSE после нескольких включений - выключений
> она пеерставала грузится ))))Вот почему проблемы с Linux возникают сугубо у БСДшников?
>> Пользователям предлагается использовать btrfs для корневого раздела.
> юзеры просто ничего не знают что это за ФСПростите, продакшн обычно подразумевает наличие вменяемого администратора.
> Вот почему проблемы с Linux возникают сугубо у БСДшников?
у меня проблем с линуксом нет, потому что я больше его ен использую ,я доволен, а вот друзья которые ищут для себя линукс, только в цацки играются и горем страдают, то проблемы не мои, я лишь написал факт.
> только в цацки играются и горем страдают,Сразу видно "объективное" и "непредвзятое" отношение к вопросу. И вообще проекция своих проблем на окружающих.
Простите, если смотреть с моей колокольни, например то в той же фре с ФС полный ахтунг вообще. На выбор тормозной и ископаемый UFS vs опять же тормозной и странный ZFS, который к тому же памяти хочет дофига. Как по мне так это куда более галимый выбор чем в лиунуксах есть. Не говоря уж о том что не осталось разработчиков способных всерьез разрабатывать файловые системы: все вкусности или утянуты или у оракла, или из ZFS on linux или еще откуда. А сами чего? Ничего? Ну да, крутые разработчики.
> Простите, если смотреть с моей колокольни, например то в той же фре
> с ФС полный ахтунг вообще. На выбор тормозной и ископаемый UFS
> vs опять же тормозной и странный ZFS, который к тому же
> памяти хочет дофига.UFS у меня на десктопе, не тормозит, флешку смонированую вытакал, для эксперемента еще питание вырубал, работает и грузится, пофиксили, может вспомнить что похожие плюшки в линуксе были с ядром еще 2.6 или 2.4 точно не помню. А раз луноходам не нравится ZFS, так чего его ставят на сервера линукс ? да , да люди пишут что были на btrfs, но выбрали ZFS, так и секрет сисек не раскрыт в этом вопросе.
как пишут люди, так и досих пор не работает с RAID 5-6, сколько еще пилить прийдется ?
> Как по мне так это куда более галимыйну так это ваше мнение, оно других интерисует ?
> выбор чем в лиунуксах есть.да там выбор настолько большой даже в тех же ядрах, дистрибутивах, ФС, надстроек над досом что скоро черт там сломает голову, и закопает все вместе.
> Не говоря уж о том что
> не осталось разработчиков способных всерьез разрабатывать файловые системы: все вкусности
> или утянуты или у оракла, или из ZFS on linux или
> еще откуда. А сами чего? Ничего? Ну да, крутые разработчики.да ну, у оракла група делится на две части, одни пилят линукс, а другие солярис, ZFS еще sparc начали делать, и не для линукса, ФС просто портировали в FreeBSD, в линуксе, это за лицензии дополнительный костыль, тоесть модуль
Потому что некоторые закостеневшие линуксоиды в упор не видят некоторых проблем в последних ядрах, так как кроме Linux их ничего не интересует и им не с чем сравнить. От того и проблем у них нет. А когда человек приходит с другой системы, то ему сразу бросаются в глаза некоторые вещи.
На днях, один фанатичный представитель пытался меня убедить, что у меня плохой винт и поэтому он плохо работает с ядрами 3.5.x и 3.6.x. Хотя я ему несколько раз подчеркнул, что на BSD проблем нет. В итоге он мне наплел всевозможной ереси, но даже не допустил мысли, что проблема в ядре. А на самом деле оказалось, что проблема решается патчами nrj к ядру.
> А на самом деле оказалось, что
> проблема решается патчами nrj к ядру.я уже в другой ветке спрашивал - что за патчи nrj где посмотреть? или они входят только в состав бинарных сборок ядра?
Все патчи доступны по адресу https://github.com/magos-linux/magos-linux/tree/master/make_...Но какие именно решают проблему когда обычное Linux ядро начинает лагать под нагрузкой работы с диском, я пока не разбирался. Да и не для того я с BSD хочу свалить на десктопе, чтобы самому что-то патчить и компилить. Я хочу комфорта - кнопка обновить и все работает. :) А пока что я такого на Linux тоже не встретил. В той же ROSA на текущий момент немало косметических багов, но хоть ядро не тормозное.
> Все патчи доступны по адресу https://github.com/magos-linux/magos-linux/tree/master/make_...спасибо!
Странно, но кроме патча для AUFS и хитрого скрипта для сборки ядра я там ничего не нашел...
остальные патчи там тянутся с ftp://ftp.kernel.org/...> Но какие именно решают проблему когда обычное Linux ядро начинает лагать под
> нагрузкой работы с диском, я пока не разбирался.хе и я не нашел...
использую вот это https://github.com/damentz/zen-kernel а по верх него бубунта :) с "кнопкойобновить"> Да и не для того я с BSD хочу свалить на десктопе, чтобы самому
> что-то патчить и компилить. Я хочу комфорта - кнопка обновить и
> все работает. :) А пока что я такого на Linux тоже
> не встретил. В той же ROSA на текущий момент немало косметических
> багов, но хоть ядро не тормозное.да ядра в принципе не тормозные - они просто хреново интерактивные....
> Все патчи доступны по адресу https://github.com/magos-linux/magos-linux/tree/master/make_...
> Но какие именно решают проблему когда обычное Linux ядро начинает лагать под
> нагрузкой работы с диском, я пока не разбирался.хм похоже они все тут https://github.com/magos-linux/magos-linux/blob/master/make_...
> Все патчи доступны по адресу https://github.com/magos-linux/magos-linux/tree/master/make_...хм, а вообще получается что основная часть изменений из патчей - те же что и в zen ядре...
> Я хочу комфорта - кнопка обновить и все работает.что, не дают? требуй назад деньги.
Браво! У Вас очень остроумный и искрометный юмор.
а я не шутил.
fsync speedups это по идее избавление наконец от тех самых нереальнх тормозищ при git fetch;git rebase, yum update ? Хотелось бы попробовать, хотя вот тут пишут http://article.gmane.org/gmane.comp.file-systems.btrfs/21540 что все равно как только места мало - жуть гарантирована. Про это в ченджлоге ни слова. Кому не лень, отпишитесь, как оно на новом ядре.
еще помнится шишкин про это писал...
всем пофиг, они там плюшки пишут, а не ФС
> всем пофиг, они там фс для жестких дисков и SSD делают, а не для сидюков и флоппиков.//fixed.
Это повод треть диска пустой держать?
> Это повод треть диска пустой держать?Ну не треть а на большом диске скорее 10-15%, при том эта рекомендация валидна для вообще любой ФС. Особенно на механических дисках. Просто CoW имеет шансы залететь в штопор более круто чем классический дизайн.
Тем более с btrfs нет никаких особых проблем: перестало хватать места - воткнул в пул новый диск - места опять стало дофига. И никаких деструктивных мероприятий и перемещения данных. Хотя можно пнуть ребаланс, чтобы нагрузка на диски равномерно размазалась.
Этор теория. Волшебная розовая мечта. На практике совсем наборот, так что давно уже не смешно. И до сих пор решения нет. http://news.gmane.org/gmane.comp.file-systems.btrfs
> уже не смешно. И до сих пор решения нет. http://news.gmane.org/gmane.comp.file-systems.btrfsАга, прикольно, сообщение начинается с слов:
"Last week we had 2 times an "uncorrectable ecc memory error" crash"Пардон, если у граждан битая оперативка - там все что угодно может быть порушено в виде как угодно. То что btrfs с настолько крайвыми случаями хорошо справится прямо сейчас - не факт, такое обычно более-менее нормально начинает работать через несколько лет активной эксплуатации. И то не у всех. Вон у MS например ntfs.sys в бсод на некорректных сруктурах падает по сей день. А это, на минуточку, более 15 лет юзания в каждой дырке. Равняться на таких граждан конечно не стоит, но считать всех вокруг волшебниками тоже как-то странно. Код пишут люди. Они сажают баги. И не всегда могут предусмотреть что будет в краевых условиях.
К слову - а сейчас есть ещё возможность получить ECC в домашнем компе приличной производительности и функциональности, не покупая серверного процессора?
> Тем более с btrfs нет никаких особых проблем: перестало хватать места —
> воткнул в пул новый диск — места опять стало дофига.типичный домашний сценарий!
> типичный домашний сценарий!Глядя на то сколько SATA разъемов на обычной писючной мамке нынче - не настолько уж и неправда. Т.е. при желании воткнуть еще 1 винч в типовой писюшник вполне можно.
при желании и на руках ходить можно.
> при желании и на руках ходить можно.Не, не так. Вот у людей 2 ноги, 2 руки, 2 глаза, .... но в принципе можно ограничить себя использованием 1 руки, прыгать на 1 ноге и смотреть на мир 1 глазом. Т.е. интерфейсы есть но на благо не задействованы.
«хочешь бегать быстрее? пришей третью ногу! место на теле есть.»
Посмотрели на разъёмы? Очень хорошо.
А теперь посмотрите на отсеки для дисков.
Особенно у нынешних домашних ПК нормальных людей, которые теперь моноблоки или медиаплееры в крошечных корпусах.
Наверно самое интересное ядро за этот год. В плане рефакторинга устаревшего кода. Всегда интересно наблюдать за такими крупными внутренними реорганизациями.
> Наверно самое интересное ядро за этот год.Весьма конкретно перепахали. И при том - вполне себе работает, ничего особо не отвалилось вроде. Крутота.
я не понял, что они сделали с nouveau? чем это стало лучше?
>>в состав драйвера добавлен код для обеспечения управления кулером, работающий на устройствах серии NV40У меня gf6600 но на ней кулер уже давно сгорел, поэтому для меня наверное ничего не изменится:)
В терминологии nouveau NV40 — это GF6xxx и 7xxx, NV50 — 8xxx и 9xxx.
> В файловую систему Ext4 добавлена поддержка изменения размера на летуА максимальное количество инодов на лету уже можно изменять?
> Добавлена рабочая реализация пространств имён для идентификаторов пользователей (user namespaces)
Вкусно
>А максимальное количество инодов на лету уже можно изменять?нет конечно, и никогда не будет
>>А максимальное количество инодов на лету уже можно изменять?
> нет конечно, и никогда не будетВ случае ext[2-4] (для других не знаю - лень проверять) оно и сейчас прекрасно изменяется: достаточно изменить размер ФС (resize2fs).
>В случае ext[2-4] (для других не знаю - лень проверять) оно и сейчас прекрасно изменяется: достаточно изменить размер ФС (resize2fs).В сторону увеличения - да, по пропорции, в сторону уменьшения - тоже, но с оговорками, без изменения размера раздела/переформатирования - даже теоретически нет, enjoy your wasted space
>>В случае ext[2-4] (для других не знаю - лень проверять) оно и сейчас прекрасно изменяется: достаточно изменить размер ФС (resize2fs).
> В сторону увеличения - да, по пропорции, в сторону уменьшения - тоже,
> но с оговорками, без изменения размера раздела/переформатирования - даже теоретически
> нет, enjoy your wasted spaceПоделитесь секретом телепатии, пожалуйста.
оригинальный вопрос был
>А максимальное количество инодов на лету уже можно изменять?оригинальный ответ был:
>нет конечно, и никогда не будет
>оригинальный вопрос был
>оригинальный ответ былОк, перейдём к практике: уменьши мне число инодов на любом произвольно взятом ext4-разделе, вооружившись последним ведром с утилитами, - не получается? А что ж так? :)
На практике первым возникает вопрос "зачем?" - чтобы количество инодов заиграло это раз в десять FS уменьшить надо?
>На практике первым возникает вопрос "зачем?" - чтобы количество инодов заиграло это раз в десять FS уменьшить надо?Чтобы количество инодов заиграло достаточно выйти за рамки негласного "не создавайте много мелких файлов", и без всякого уменьшения FS.
А "зачем?" - вопрос хороший, позволяет аргументированно демотивировать
> А "зачем?" - вопрос хороший, позволяет аргументированно демотивировать"Зачем?? - это отличный вопрос. Чтобы кто-то подорвался решать некую проблему - надо сначала разобраться в чем она заключается, кому мешает жить и как с ней бороться чтобы в других местах не навредить.
А чинить то что не сломано чисто для красоты, тратя в результате ресурсы на какой-то непродуктивный и бесполезный крап - прерогатива адептов академических направлений (e.g. *bsd), а не инженерного подхода.
Разница в том что на выходе у академиков получается рафинированный и красивый но нифига не ездящий экспонат. А у инженеров со всеми костылями и подпорками, обработкой напильником по месту, в смазке и копоти - выглядит порой жутковато. Зато молотит от души.
>"Зачем?? - это отличный вопрос. Чтобы кто-то подорвался решать некую проблему - надо сначала разобраться в чем она заключается, кому мешает жить и как с ней бороться чтобы в других местах не навредить.Хорошая "вода", но можно сказать проще: "у нас тут всё гвоздями прибито, иначе никак"
>А у инженеров
До-о, - напомнить, кем ext была создана? :)
>cо всеми костылями и подпорками, обработкой напильником по месту, в смазке и копоти - выглядит порой жутковато
Ага, т.к. по-другому с ext в принципе нельзя
>Зато молотит от души.
Если не нарушать негласных правил и закрывать глаза на неудобные вещи, то да - вполне годное
> enjoy your wasted spaceЕго относительный процентаж будет весьма скромным в общем случае. Нет, если переть на принцип - на любой ФС можно скроить ФС состоящую целиком из метаданных. Но зачем? Это будут абсолютно синтетические ситуации. А дефолтная эвристика mke2fs вполне нормально работает в типовых случаях. Для НеТиповых дадены рукоятки. Фигле еще надо?
в общем для !ARM и переходить с 3.6.X нет смысла...
да ты гонишь.
дисковая подсистема, сеть, видео дрова,… — да там плюшек привалило не мелко.
прочитай сабж больше пары абзацев (в идеале до конца).
> да ты гонишь.
> дисковая подсистема, сеть, видео дрова,… — да там плюшек привалило не мелко.
> прочитай сабж больше пары абзацев (в идеале до конца).пасиба тебе, добрый ананим...
вот именно что прочитал - и из того что там наделано мне ничего не нужно....
ну раз тебе не нужно, то да, Торвальдс расстроится сильно.
> ну раз тебе не нужно, то да, Торвальдс расстроится сильно.вот и я об том же...
но за тебя он точно будет рад!
Да, для меня плюшек много привалило. И для клиента, и для сервера.
> Да, для меня плюшек много привалило. И для клиента, и для сервера.для локалхоста ? или у тебя ЛФС на сервере ?
>> Да, для меня плюшек много привалило. И для клиента, и для сервера.
> для локалхоста ?прикинь, для локалхоста. пространство имён в группах — это весьма круто и удобно. тебе, впрочем, без разницы: фкантактег открывается и без этого.
> прикинь, для локалхоста. пространство имён в группах — это весьма круто и удобно.Как впрочем и дотыкание +1 диска с приплюсовкой места на оном к ФС :P.
на своем опыте могу сказать, что заметно улучшили поддержку AMD Trinity.
На 3.6 Samsung 535U4C нормально не работал, поставил RC 3.7 - хотя бы выключаться/саспендится нормально стал.
> в общем для !ARM и переходить с 3.6.X нет смысла...А давно вы у нас выступаете истиной в последней инстанции?
>Загрузчик прошивок теперь пытается загрузить файлы непосредственно из файловой системы, без задействования udev. Наличие прошивок пока проверяется в /lib/firmware, в будущем будут добавлены гибкие настройки выбора пути;Вот она, причина конфликта Линуса с разработчиками udev. Теперь ядро само будет грузить прошивки, в том числе проприетарные, без помощи udev. Конфликт исчерпан.
>>Загрузчик прошивок теперь пытается загрузить файлы непосредственно из файловой системы, без задействования udev. Наличие прошивок пока проверяется в /lib/firmware, в будущем будут добавлены гибкие настройки выбора пути;
> Вот она, причина конфликта Линуса с разработчиками udev. Теперь ядро само будет
> грузить прошивки, в том числе проприетарные, без помощи udev. Конфликт исчерпан.Тут не совсем конфликт, они об этом давно просили.
> Вот она, причина конфликта Линуса с разработчиками udev. Теперь ядро само будет
> грузить прошивки, в том числе проприетарные, без помощи udev. Конфликт исчерпан.Не совсем так: Торвальдс и Ко просто разрубили гордиев узел, ехидно запилив механизм прямо в ядро. Они доступно показали что у ядерщиков все-равно длиннее, как бы там юзермод-разработчики не кипищевали между собой. Они просто шлепнули тапком и растерли. Кипиш сошел на нет по естественным причинам.
> Не совсем так: Торвальдс и Ко просто разрубили гордиев узел, ехидно запилив
> механизм прямо в ядро. Они доступно показали что у ядерщиков все-равно
> длиннее, как бы там юзермод-разработчики не кипищевали между собой. Они просто
> шлепнули тапком и растерли. Кипиш сошел на нет по естественным причинам.У Вас странное представление о взаимоотношениях между разработчиками usermode/kernel.
Имо логично, что прошивка, как часть самого оборудования, грузится именно ядром, а не userspace-слоем абстракции оборудования.
> У Вас странное представление о взаимоотношениях между разработчиками usermode/kernel.Нормальное - я этот цирк с конями в рассылке почитал, спасиб. Ну да, достали ядерщиков - те и бомбанули ядерными ракетами. Юзермодовцам на это ответить все-равно нечем :)
> Имо логично, что прошивка, как часть самого оборудования, грузится именно ядром, а
> не userspace-слоем абстракции оборудования.Да когда как. Если там какой-то замороченный протокол вгрузки или надо какие-то хитрые манипуляции с файлом делать, совсем не факт что столько счастья надо в ядро тянуть. Но поскольку господа окончательно упоролись, пришлось их отрезвить вот так вот, просто отобрав игрушку совсем.
>> Загрузчик прошивок теперь пытается загрузить файлы непосредственно из файловой системы, без задействования udev.
> Вот она, причина конфликта Линуса с разработчиками udev.Это, все-таки, следствие конфликта, а не его причина.
Как итог, проще оказалось запилить у себя чем (пере)убедить майнтейнеров udev. И я, лишь мельком глядя на открытую часть переписки и совершенно неадекватные понты udev'овцев во всем остальном, вполне понимаю почему.
Торвальдс в этой переписке, если вы про lklm, тоже не пушистик, но думаю вы правы.
> Торвальдс в этой переписке, если вы про lklm, тоже не пушистикОн весьма брутально тролланул этих неадекватов + ядерщики честно приложили чисто технически. Но неадекваты из udev'а это заслужили на все сто. Градус адеквата разработчиков udev в том треде поставил откровенный антирекорд.
>> Торвальдс в этой переписке, если вы про lklm, тоже не пушистик
> Он весьма брутально тролланул этих неадекватов + ядерщики честно приложили чисто технически.
> Но неадекваты из udev'а это заслужили на все сто. Градус адеквата
> разработчиков udev в том треде поставил откровенный антирекорд.Это с какой стороны смотреть.
Прогрессивные "поттеринги" от udev-ов объявили, что в ядре "всё плохо", и сделали в udev "всё хорошо", сломав системы прогрессивных пользователей распоследних версий systemd-udev-а. Торвальдс, мол, "какого собственно, чините быстро-быстро". Те - рожу кирпичём, "ой, а мы и не знаем, как его починить, но так надо -- мы ж предупреждали". Торвальдс обтёк и сделал патч. Ура, 3.7. (--Вы прослушали краткий пересказ http://lwn.net/Articles/518942/)
+++Так кто победил-то?
> +++Так кто победил-то?Торвальдс, который
1) Все-равно сделал по своему.
2) Починил.
3) Сделал этот кусок udev'а obsoleted :)
>> +++Так кто победил-то?
>Торвальдс, которыйВопрос, мне казалось был, правтически риторический. Ну, да с переходом в бейт.
Кстати, прогрессивненькие потерингики пхают свой прогрессивненький joornald в Debian: всё под тем же http://bugs.debian.org/725714 соусом поломанного _ими udev.
Хорошо ж, что есть форнутый udev, а то ж мы чуть про банду потерингов-сиверсов плохого не подумали.
всегда люблю читать ответы авторов gtk+3. или там udev какого-нибудь. особенно я люблю читать о том, как они всё поломали, чтобы героически победить Страшный Баг, о котором знало три с половиной пользователя (и они умели его обойти), оставив после фиксов дымящиеся руины.«косить под Ульриха» можно тогда, когда ты имеешь на руках железные аргументы. у Ульриха был стандарт. а эти… они как христиане: «если бога нет — значит, всё позволено!» и давай крушить.
У меня в арче на ядрах 3.4.* и последующих периодически вылезало в начале загрузки
"usb *-*: device descriptor read/64, error -32", "*-*" - всегда разные. В логах конкретики не более. Заметил, когда поменял материну на современную с usb 3.0. Погуглил, погуглил, проблема имеет место быть, но толком даже не понял, usb-контроллер (там их несколько) отваливается? Кто-то пишет, железо типа сбоит, ему отвечают, что, ну как же, под Ней то всё работает (ну, как обычно). Проверить возможности не было, так как usb 3.0 устройств у меня нема ;) Но неприятный осадочек остался.
> У меня в арче на ядрах 3.4.* и последующих периодически вылезало в
> начале загрузки
> "usb *-*: device descriptor read/64, error -32", "*-*" - всегда разные. В
> логах конкретики не более. Заметил, когда поменял материну на современную с
> usb 3.0. Погуглил, погуглил, проблема имеет место быть, но толком даже
> не понял, usb-контроллер (там их несколько) отваливается? Кто-то пишет, железо типа
> сбоит, ему отвечают, что, ну как же, под Ней то всё
> работает (ну, как обычно). Проверить возможности не было, так как usb
> 3.0 устройств у меня нема ;) Но неприятный осадочек остался.на 3.6.10 аналогично "usb *-*: device descriptor read/64, error -32", "*-*"
> ну как же, под Ней то всё работает (ну, как обычно)обычно это значит, что шindoш$ просто не пишет логи. «всё хорошо, прекрасная маркиза».
> обычно это значит, что шindoш$ просто не пишет логи. «всё хорошо, прекрасная маркиза».Да уж. Диагностика ошибок там традиционно куцая. Впрочем, чего ожидать от граждан скупивших Русиновича и сливших его утилиты? Dbgview в современных виндах вообще работает через раз. А другой удобной вьюшки отладочных сообщений тупо нет. Поэтому все хорошо... до тех пор пока оно не трапнется в бсод или не начнет явно кончаться память или что там еще.
> для ARM-систем, которым теперь не придётся формировать отдельный загрузочный образУгу, ЩАЗ. Загрузчики у всех разные. Так что в самом лучшем случае экономия на сборке ядра будет, не более. А образ - платформоспецифичен.
> (например, в каждом контейнере может быть свой root);
Кто там хотел? Получите и распишитесь.
> но она не влияет на загрузку модулей и информирует о проблемах через лог.
Оно просто метит ядро как tainted. Компромиссный вариант: не прикладывает жестко, но демаскирует активность.
IPv6 NAT... NOOOOOOOOOO
Вот вопрос тем, кто считает, что под IPv6 NAT не нужен:
Есть сетка, есть два провайдера, каждый провайдер выдаёт свой префикс IPv6. Вы считаете целесообразным менять IP-адреса у всех девайсов при переключении провайдера? А потом объяснять шефу, почему местная ынтырпрайз-бизнесс-программа потеряла связь с базой и не могла долгое время восстановить подключении, из-за того, что в её DNS-кеше сохранился старый адрес?
Не проще ли в данном случае промапить локальные IPv6-адреса на адреса предоставляемые провайдером?
> Вот вопрос тем, кто считает, что под IPv6 NAT не нужен:
> Есть сетка, есть два провайдера, каждый провайдер выдаёт свой префикс IPv6. Вы
> считаете целесообразным менять IP-адреса у всех девайсов при переключении провайдера?
> А потом объяснять шефу, почему местная ынтырпрайз-бизнесс-программа потеряла связь с базой
> и не могла долгое время восстановить подключении, из-за того, что в
> её DNS-кеше сохранился старый адрес?
> Не проще ли в данном случае промапить локальные IPv6-адреса на адреса предоставляемые
> провайдером?+++...
правильно проще, при том что менять всего лишь префикс - несколько первых байт адреса. а вот если этого нет то нагородить придется... так что кому не нужен пусть молчат - не для них писано.
> считаете целесообразным менять IP-адреса у всех девайсов при переключении провайдера?Хм... надо же, даже какой-то реальный юзкейс нарыли. Хотя за написание отваливающихся программ руки надо отрывать от того места от которого они растут.
это не юзеркейс, это непонимание основ
> это не юзеркейс, это непонимание основНе, ну почему? Сойдет для каких-то специфичных случев. Хотя в 99.9% случаев это натурально полный изврат.
Хм. Как будто кто-то не почитал TFM на тему ipv6 roaming?
А если два провайдера подключены постоянно? :-)
Btrfs по-тихоньку движется вперед, может через пару лет уже будет торт.
потихоньку
> потихонькуКоллеги, расстреляйте негодяя! Он хронически забывает ставить заглавные буквы и точки.
>Загрузчик прошивок теперь пытается загрузить файлы непосредственно из файловой системыПочему-то есть ощущение в этом чего-то неправильного.
Ну, это кому как. С моей точки зрения то, что ядро может в одиночку поднять железо, не имею юзерленда вообще - это очень даже правильно.
> Почему-то есть ощущение в этом чего-то неправильного.Гм, учитывая что ядро по жизни файлы и сервирует всем остальным, неправильно и странно - это когда оно само себя сервировать вдруг почему-то не может :)
>реализацию GRE и NAT для IPv6OMG, а раньше этого что, не было???
>>реализацию GRE и NAT для IPv6
> OMG, а раньше этого что, не было???Дык ipv6 нат не особо то и уперся. Хотя конечно есть обезьяны не понимающие разницу между stateful firewall и натингом, но мы таких рассматривать не будем.
Просто на BSD это уже давненько было. Я думал, что и на Линуксе уж тем более есть. А то, что не используется, так и IPv6 пока что "не особо то и уперся." Вот настанет конец све^W IPv4, тогда сразу и станет актуально.
> Просто на BSD это уже давненько было.Ну да, конечно, натинг ipv6 - самая важная и востребованная фича. А всякая там хрень типа виртуализации или контейнеров нормальных - это для лохов педальных :) </sarcasm>
> Поддержка протокола VXLAN для туннелирования виртуализированных сетей второго уровня поверх сетей третьего уровня. Указанный протокол позволяет обойти ограничение на 4096 VLAN-ов (в VXLAN используются 24-разрядные идентификаторы);Что люди не придумаю что бы не использовать q-in-q протокол...
>> Поддержка протокола VXLAN для туннелирования виртуализированных сетей второго уровня поверх сетей третьего уровня. Указанный протокол позволяет обойти ограничение на 4096 VLAN-ов (в VXLAN используются 24-разрядные идентификаторы);
> Что люди не придумаю что бы не использовать q-in-q протокол...Если под q-in-q вы имеете ввиду IEEE 802.1ad (двойной VLAN тег), то VXLAN сильно и местами принципиально отличается.
q-in-q - это чистый Layer 2 (ну или Layer 2 over Layer 2 - зависит от use case) со всеми вытекающими.
VXLAN же это Layer 2 over Layer 3, а это уже совершенно другие возможности и, как следствие, совсем другая область применения.
Но несомненно, общее у них то, что они оба НЕ ТОЛЬКО "позволяют обойти ограничение на 4096 VLAN-ов".
> Но несомненно, общее у них то, что они оба НЕ ТОЛЬКО "позволяют
> обойти ограничение на 4096 VLAN-ов".Ну просто то чудо похоже на бсдшника с батхертом, судя по его чудному нику. О том что бывают географически разнесенные структуры например с виртуалками, которые хочется объединить именно через L3 он явно не в курсах.
стандартные вопросы: какое количество новаго железа (и функций) она стала поддерживать того, которое не поддерживают другие ветки ядра? (и есть ли в других ветках ядра что-нибудь то, что не поддерживается в этой?) Сколько чего-либо неподдерживаемаго осталось теперь в связи с этим релизом? (и есть ли в "3.7" то, чего поддержка прекращена?)
В состав каких дистрибутивов войдет эта ветка? Могут ли быть такие уже существующие дистрибутивы, в которых ихнее ядро может быть смысл поменять на это? (а тогда в каких случаях? (и не может ли быть так, это лучше будет сделать не сейчас а позже? (по тому что некоторыя ветки претерпевают порой даже и более полусотни изменений в течение своего срока существования (а у этой интересно каким и то и то будет?))))
Через сколько времени возможны окончательные ответы на эти вопросы по данной ветке ядра?
(кто ее уже как следует опробовал- напишите, как она? (а следующая когда будет и что в ней будет? (сколько стоит ветки поддерживать и создавать новые?)))
>[оверквотинг удален]
> на это? (а тогда в каких случаях? (и не может ли
> быть так, это лучше будет сделать не сейчас а позже? (по
> тому что некоторыя ветки претерпевают порой даже и более полусотни изменений
> в течение своего срока существования (а у этой интересно каким и
> то и то будет?))))
> Через сколько времени возможны окончательные ответы на эти вопросы по
> данной ветке ядра?
> (кто ее уже как следует опробовал- напишите, как она? (а следующая
> когда будет и что в ней будет? (сколько стоит ветки поддерживать
> и создавать новые?)))Стандартный ответ: __________.
Ну ты понял.