Линус Торвальдс на неделю раньше прогнозируемого срока представил (https://lkml.org/lkml/2012/9/30/152) релиз ядра Linux 3.6 (http://www.kernel.org). В новую версию принято около 9 тысяч исправлений от более чем 1200 разработчиков,
размер патча - 34 Мб (изменения затронули 8296 файлов, добавлено 528478 строк кода, удалено 256811 строк). Около 42% всех представленных в 3.6 изменений связаны с драйверами устройств, примерно 23% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 15% связано с сетевым стеком, 6% - файловыми системами и 4% c внутренними подсистемами ядра.
Наиболее интересные новшества (http://kernelnewbies.org/Linux_3.6) ядра 3.6:
-
Сетевая подсистема- Включение (http://lwn.net/Articles/507065/) наработок (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...) по использованию коротких очередей TCP пакетов (TSQ - TCP Small Queues), подразумевающих использование сокращённого буфера для очереди отправляемых через каждый сокет пакетов. Указанная возможность разработана в рамках инициативы (http://www.opennet.me/opennews/art.shtml?num=29734) по борьбе с негативным влиянием промежуточной буферизации пакетов (Bufferbloat) сетевым оборудованием. Тесты показали, что уменьшение размера буфера до разумных величин не влияет на пропускную способность, но позволяет снизить негативное влияние излишней промежуточной буферизации пакетов на однородность потока (jitter) и время прохождения пакетов (latency), за счёт сокращения числа находящихся в очереди исходящих пакетов и, соответственно, уменьшения времени нахождения пакетов в очереди. Регулировать лимит на размер очереди можно через файл /proc/sys/net/ipv4/tcp_limit_output_bytes (значение по умолчанию 128 Кб).
- Поддержка (http://lwn.net/Articles/508865/) режима быстрого открытия TCP-соединений (TFO (http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-01) - TCP Fast Open), позволяющего сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения, и давая возможность отправки данных на начальном этапе установки соединения. TFO пока отнесён к экспериментальным TCP-расширением, так как соответствующая опция пока не одобрена IANA. По оценке компании Google, разработавшей TFO, для примерно 33% HTTP-запросов браузеру требуется предварительная отправка одного RTT-пакета для установки TCP-соединения с удалённым хостом. Большинство HTTP-ответов укладываются в начальное окно перегрузки величиной 10 пакетов, удваивая время отклика. Режиме TFO позволяет снизить накладные расходы за счёт возможности включения HTTP-запроса в начальный TCP SYN пакет. В итоге, активация TFO позволяет сократить время загрузки страниц в среднем примерно на 10%, а в некоторых ситуациях до 40%.
-
Дисковая подсистема, ввод/вывод и файловые системы
- В состав ядра интегрирована подсистема VFIO (http://git.kernel.org/linus/4a5b2a20ec87384eeb19e70991e7e15a...)
(Virtual Function I/O), нацеленная на предоставление средств для создания виртуализированных драйверов устройств, работающих в пространстве пользователя. Подсистема была создана разработчиками системы виртуализации KVM для упрощения создания драйверов для прямого доступа к PCI-устройствам из гостевых систем, обеспечивающих максимальную производительность и минимальное время задержки, но не требующих запуска отдельных компонентов уровня ядра на стороне хост-системы. В частности VFIO предоставляет более безопасный механизм, чем UIO, позволяющий обойтись без использования специфичного KVM PCI кода и выносящий драйверную логику в пространство пользователя, используя для обеспечения изоляции IOMMU Groups. Поддержка VFIO ожидается в будущих выпусках QEMU.- Для файловой системы Btrfs добавлена поддержка команды send (http://lwn.net/Articles/506244/), позволяющей вычислить различия между двумя подразделами Btrfs и выделить результат в обособленном виде (информация о различиях сохраняется в файле). В дальнейшем, сохранённая информация о различиях может быть использована при помощи команды "receive" для накатывания изменений к снапшоту для доведения его до состояния другого снапшота. Указанная возможность окажется полезной при организации инкрементального копирования или при организации зеркалирования содержимого разделов. Формирование слепка различий производится командой "btrfs send -i oldsnap snapshot", для применения изменений к снапшоту предусмотрена команда "btrfs receive".
Кроме того, в Btrfs добавлена (http://git.kernel.org/linus/8ea05e3a4262b9e6871c349fa3486bcf...) поддержка квот для отдельных подразделов, позволяющих определить как много места могут занимать отдельные области ФС.
- Информация о квотах для EXT4 отныне не сохраняется в видимых файлах, а размещается в форме метаданных, внутри скрытых inode.
-
Виртуализация и безопасность
- Поддержка групп IOMMU (IOMMU Groups (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...)), позволяющих обеспечить изоляцию устройств PCI и PCIe с использованием технологий виртуализации ввода/вывода AMD-Vi и Intel VT-d. IOMMU Groups решает проблему с невозможностью изоляции одного PCI-устройства от другого. Для устройств которые не могут быть изолированны по отдельности поддерживается их объединение в одну группу. IOMMU Groups, в частности, выступает в качестве основы для вышеотмеченной подсистемы VFIO.-
Память и системные сервисы- Проведена (http://lwn.net/Articles/507794/) работа по рефакторингу заголовочных файлов, в рамках которой произведено разделение по разным иерархиям директорий заголовочных файлов для UAPI (Userspace API) и KAPI (Kernel API). Подобное разделение позволит более явно выделить необходимые только для ядра заголовки (например, разработчики дистрибутивов получат возможность подготовить сокращённый пакет только с заголовками UAPI). Кроме того проведена работа по упрощению сложившейся усложнённой и запутанной схемы внутренних зависимостей между заголовочными файлами, например, разработчики сталкивались с проблемами добавления inline-функций в заголовочный файл, так как нередко в таких функциях необходимо было использовать компоненты из других заголовочных файлов;
- Поддержка протокола EFI Handover Protocol на уровне ядра, позволяющего упростить написание EFI-загрузчиков и ускорить процесс загрузки на EFI-системах;
- Добавлен режим "Suspend to both", комбинирующий спящий и ждущий режимы, путем перехода в ждущий режим после предварительного сохранения образа памяти на диск. В ситуации когда запас аккумулятора иссяк, новый режим позволяет восстановить работу через загрузку с диска дампа памяти, как при спящем режиме. Если запас энергии не исчерпан, восстановление будет совершено в ждущем режиме;-
Оборудование и аппаратные архитектуры
- Обновлен DRM-драйвер для карт Intel, интегрированы наработки по оптимизации производительности.
- В DRM-драйвере Radeon по умолчанию включена поддержка PCI Express 2.0.
- В драйвер "intel_idle" добавлена поддержка дополнительных режимов экономии энергии, появившихся в Intel Ivy Bridge. Для просмотра статистики об изменении частоты процессора и его нахождения в состоянии простоя (idle) в состав дерева ядра включён переработанный вариант утилиты "turbostat".- В подсистему perf добавлена поддержка метрик производительности "uncore", реализованных в CPU Intel Nehalem и Sandy Bridge.- При сборке для 64-разрядных процессоров на базе архитектуры x86 добавлена поддержка загрузочных опций "reboot=bios" и "reboot-cpu".URL: https://lkml.org/lkml/2012/9/30/152
Новость: http://www.opennet.me/opennews/art.shtml?num=34976
>При сборке для 64-разрядных процессоров на базе архитектуры x86 добавлена поддержка загрузочных опций "reboot=bios" и "reboot-cpu"Я правильно понимаю:
"reboot-cpu" - это ребут без перезагрузки BIOS?
Нет. Сложно было по ссылке сходить? Переводчик не осилил фразу "Allow reboot=bios and reboot-cpu override" (подсказка по поводу качества всей "статьи").Раньше ты мог указать номер ЦП, на котором будет инициирован сброс, только на x86_32, а теперь и на x86_64 тоже.
> Нет. Сложно было по ссылке сходить? Переводчик не осилил фразу "Allow reboot=bios and reboot-cpu override" (подсказка по поводу качества всей "статьи").Вообще-то в оригинале написано "The x86 architecture now supports the reboot=bios and reboot-cpu command-line options on 64-bit processors (as well as on 32-bit, which has been supported for a long time)". Непонятно где вы про override нашли.
> Вообще-то в оригинале написано "The x86 architecture now supports the reboot=bios and reboot-cpu command-line options on 64-bit processors (as well as on 32-bit, which has been supported for a long time)". Непонятно где вы про override нашли.В комментарии к коммиту. Непонятно, где вы нашли "оригинал".
> Раньше ты мог указать номер ЦП, на котором будет инициирован сброс, только
> на x86_32, а теперь и на x86_64 тоже.А в чем польза такой опции, если не секрет?
Да, посмотрел сейчас на turbostat с 3.5.4 - как-то не очень информативно выглядит. Ну, посмотрим новый на днях в Арчике ;)
Ммм штеуд будет еще быстрее работать =)
Еще mesa 9.1 с kde 4.9.2 дождаться, и вообще замечательно=)
mesa 9.1 врятли будет. Скорее всего сразу 10.0(если не 11.0). У них смена мажорных версий происходит при смене версии поддерживаемого OpenGL. В следующий релиз обещают добавить 3.2 а возможно даже 3.3.
> обещают добавить 3.2 а возможно даже 3.3.наоборот. 3.3 уже готово, т.к. там нету шовшевст сложных в реализации. Сложные онные в 3.2
Я передал сказанное одним из разработчиков. Будет 3.2 и скорее всего будет 3.3. Я знаю что там для 3.3 практически все готово. Но почему то говоривший разработчик не был уверен на 100% насчет 3.3.
> наоборот. 3.3 уже готово,...оно должно включать в себя 3.2, которого пока нет. По поводу чего "готово" - забавно звучит :). Ну да, автомобиль собран. Хоть сейчас заводи и езжай. Сразу после того как установишь двигатель и прикрутишь колеса ;)
> Ну да, автомобиль собран. Хоть сейчас заводи и езжай. Сразу после того как установишь двигатель и прикрутишь колеса ;)Если двигатель и колеса действительно от этой машины, и есть необходимый инструмент - операции вполне тривиальные, кстати. Вот если бы были от другой модели...
> Если двигатель и колеса действительно от этой машины, и есть необходимый инструмент
> - операции вполне тривиальные, кстати.Загвоздка в том что как-то вдруг оказывается что их сборку надо еще сначала закончить. А только потом можно будет ставить. При этом извольте сами написать программу для CNC машин чтобы они нужные детали выпилили. И вот когда все будет готово - тогда все просто, да :)
Как я понимаю, RHEL7/OL7 будет основан именно на этом ядре.Ну а мы ждем 3.7 с поддержкой IPv6 NAT.
> Ну а мы ждем 3.7 с поддержкой IPv6 NAT.slowpoke, залогиньтесь!
> slowpoke, залогиньтесь!Я что-то пропустил?
> Я что-то пропустил?Да. Залогиниться забыл!
> Да. Залогиниться забыл!Не надо путать "забыл" и "лень".
>IPv6 NATно зачем?
>>IPv6 NAT
> но зачем?Типа, редирект локальных портов в волшебном мире IPv6 не востребован?
Опять же, зачем, если у любого устройства есть свой адрес?
> Опять же, зачем, если у любого устройства есть свой адрес?Есть подозрение, что для того что бы иметь возможность управлять доступом из
внутренней ipv6 сети во внешнюю.
Вопрос о целесообразности ipv6 для внутренней сети предприятия спорен,
но теоретически есть больше свободы по сознанию разделенных подсетей (так как адресноe
пространство в ipv6 больше чем в ipv4).
Как то так)
>> Опять же, зачем, если у любого устройства есть свой адрес?
> Есть подозрение, что для того что бы иметь возможность управлять доступом из
> внутренней ipv6 сети во внешнюю.Ну так это задача фаервола на границе сети. Использовать NAT вместо правила блокировки по-умолчанию форвардинга пакетов с внешнего интерфейса на внутренний несколько глупо, не находите?
> Вопрос о целесообразности ipv6 для внутренней сети предприятия спорен,
> но теоретически есть больше свободы по сознанию разделенных подсетей (так как адресноe
> пространство в ipv6 больше чем в ipv4).
> Как то так)На первый взгляд это так, а на практике оказывается, что конечная сеть не может быть меньше, чем /64. Т.е. реально /48 ipv6-сеть от /8 ipv4-сети (при дроблении до размера минимального блока в /24) отличается в плане адресации только тем, что в конечную сеть можно запихнуть больше, чем 254 устройства.
на практике для организаций:
- получить /8 в4 нереально, их просто не осталось столько, а /48 можно получить без проблем прям щас хоть через тунель хоть черей райп.
- либо использовать 10.0.0.0/8, но через прокси и как правило всего 1 в4 адрес (или как с провом договоришся).NAT в в6 это по сути РАТ - трансляция префикса, штука вполне нужная если есть Multihomed подключение без своей ас, + conntrack все таки нужен в некоторых случаях (типа фтп). хотя мне не понятно почему не ввели расширение заголовка для пат - была б стандартная фича со стандартной обработкой
> на практике для организаций:
> - получить /8 в4 нереально, их просто не осталось столько, а /48
> можно получить без проблем прям щас хоть через тунель хоть черей
> райп.Если речь идет о внутренних сетях, да еще и /8, то использовать для этого блок реальных адресов несколько излишне.
> - либо использовать 10.0.0.0/8, но через прокси и как правило всего 1
> в4 адрес (или как с провом договоришся).В /8 сетях уж точно не один-единственный шлюз ставится. Да и речь-то шла как бы об удобстве распеределения подсетей.
> NAT в в6 это по сути РАТ - трансляция префикса, штука вполне
> нужная если есть Multihomed подключение без своей ас, + conntrack все
> таки нужен в некоторых случаях (типа фтп). хотя мне не понятно
> почему не ввели расширение заголовка для пат - была б стандартная
> фича со стандартной обработкойСкорее, был бы стандартный костыль. IPv6 изначально дизайнился так, чтобы адресов точно хватило всем. Если хотите резать доступ, есть брандмауеры. Использовать вместо брандмауеров NAT-боксы глупо, если есть возможность этого не делать.
>[оверквотинг удален]
> В /8 сетях уж точно не один-единственный шлюз ставится. Да и речь-то
> шла как бы об удобстве распеределения подсетей.
>> NAT в в6 это по сути РАТ - трансляция префикса, штука вполне
>> нужная если есть Multihomed подключение без своей ас, + conntrack все
>> таки нужен в некоторых случаях (типа фтп). хотя мне не понятно
>> почему не ввели расширение заголовка для пат - была б стандартная
>> фича со стандартной обработкой
> Скорее, был бы стандартный костыль. IPv6 изначально дизайнился так, чтобы адресов точно
> хватило всем. Если хотите резать доступ, есть брандмауеры. Использовать вместо брандмауеров
> NAT-боксы глупо, если есть возможность этого не делать.ну раз это кастыль тогда реализуй без него подключение к 2м провам чтоб в случае падения одного канала пользователи в организации не заметили за исключением разрыва текущих сессии, чтоб без бгп и своей ас и gb... хотяб идею. и чтоб без костылей!
> ас и пи...исправил
> чтоб без бгп и своей ас
> и чтоб без костылей!"мне, пожалуйста, с костылями, но без костылей!"
Вы, между тем, ради каких-то странных целей предлагаете на уровне протокола ip, ничего про порты не знающего, вкорячить специальное костылное поле.
>> чтоб без бгп и своей ас
>> и чтоб без костылей!
> "мне, пожалуйста, с костылями, но без костылей!"
> Вы, между тем, ради каких-то странных целей предлагаете на уровне протокола ip,
> ничего про порты не знающего, вкорячить специальное костылное поле.ну если тебе для резервирования обязательно нужны ас и бгп то костыли видимо у тебя в голове. В приведённом примере это нормальное место использования данного механизма.
офису из 5ти человек сидящих на инете ас и бгп... охренеть-зажраться...
> Есть подозрение, что для того что бы иметь возможность управлять доступомСэр, для этого есть файрволлы!
> Опять же, зачем, если у любого устройства есть свой адрес?Скрыть устройство сети? Из соображений удобства управления и в некоторой степени - безопасности?
> Из соображений удобства управленияМудохание с управлением редиректами и портфорвардом, несомненно, куда более удобно чем просто автоконфигурация клиентов с получением адресов из подсетки.
Для контроля доступа - фаер настроить надо. Можно stateful, если надо чтоб кого попало внутрь не пущало.
А вот так - опять всякие FTP, RTSP, SIP, ... ... ... - будут застревать, eh? При том ну ладно когда административно давят нормально, явно вкорячив правило. А то ведь получается полудохлый зомбак, где то работает через раз или после прыжков с бубном, или видео только в 1 сторону прет, или еще какая напасть. Вроде и не труп, но вроде и не совсем живой. Просто он такой из-за того что какие-то му... сломали хребтину логике протокола.
> некоторой степени - безопасности?
Security through obscurity? Неважнецкая практика.
> Поддержка групп IOMMU (IOMMU Groups), позволяющих обеспечить изоляцию устройств
> PCI и PCIe с использованием технологий виртуализации ввода/вывода AMD-Vi
> и Intel VT-dО да! Вкуснота :). Алсо радуют твики TCP, приятно что сделали "Suspend to both", да и PCI-E 2.0 по дефолту не лишний :)
Убунтоводам и убунтийцам на заметку: заморозка ядра намечена на 4 октября, ядро 3.6 ещё может войти в грядущий релиз 12.10.
ох вряд ли
Ага, а Торвальдс так торопился! Специально на неделю раньше релиз перенес, лишь бы в новую Убунту попасть.
>> Пользователи нормальных дистров и так получают свежие версии ядра, без проблем.....
> В убунте нужно проделать большую работу по снижению стабильности и скорости работы
> ядра.
> Так что просто взять ванилу, как в каком-нибудь арче - не вариант.Ubuntu == Debian Testing (про стабильность)
ну да ну да,
а еще мсье забыл что те кому нужна стабильность пользуют RH/SLES/Debian
а те, кому актуальное по для дома, остальное.
> Ubuntu == Debian Testing (про стабильность)Да фиг там. У дебиана в тестинге несколько раз были факапы с отвалом груба и раннего рамдиска. У убунтуев такого ...ца нет.
Ага, им не до груба, у них десктоп отваливается )))
Ядра Ubuntu таки собираются в течении для после релиза свежего ядра, в т.ч. RC и лежат в официальном репозитории: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/
И таки они стабильны, сам обновлял, если все настройки предыдущего скопировать, что в прочем справедливо для любого другого дистрибутива.
> И таки они стабильны, сам обновлял, если все настройки предыдущего скопировать, что
> в прочем справедливо для любого другого дистрибутива.Какие-такие настройки уже готового ядра вы копируете? =))
> Какие-такие настройки уже готового ядра вы копируете? =))Может он про конфиг опций сборки ядра?
Именно! Некорректно выразился.
> Именно! Некорректно выразился.Ну вон там -> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal есть готовые ядра. Собранные вроде с более-менее обычным конфигом. Так что даже копировать ничего не надо. И даже запакетировано уже. В общем мечта лентяев :)
> Ядра Ubuntu таки собираются в течении для после релиза свежего ядра, в
> т.ч. RC и лежат в официальном репозитории: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/
> И таки они стабильны, сам обновлял, если все настройки предыдущего скопировать, что
> в прочем справедливо для любого другого дистрибутива.Fixed:
Ядра LINUX ДЛЯ Ubuntu таки собираются в течении для после релиза свежего ядра
> Ядра LINUX ДЛЯ Ubuntu таки собираются в течении для после релиза свежего ядраЛамеры не способные зайти в эбаут на сайте убунты и прочитать что это линукс - это забавно, да :)
>> Ядра LINUX ДЛЯ Ubuntu таки собираются в течении для после релиза свежего ядра
> Ламеры не способные зайти в эбаут на сайте убунты и прочитать что
> это линукс - это забавно, да :)Инвалидоориентированность дистра, что как бы намекает)
> Убунтоводам и убунтийцам на заметку: заморозка ядра намечена на 4 октября, ядро
> 3.6 ещё может войти в грядущий релиз 12.10.Я и так -RC6 на убунту вкатил. Работает. А что ему будет то? У них вообще -RC получше иного релиза получается.
в состав каких дистрибутивов оно войдет? В каких случаях может быть смысл поменять ядро на это в какой либо установленной и работающей ОС? (либо может ли что из элементов "3.6" появиться в апдейтах других веток ядра?) Какое количество новых устройств оно стало поддерживать? (и есть ли такое старое железо, которое в ней поддерживаться перестало?)
Когда выйдет следующее и что в нем будет?
Может ли ядро "3.6" попасть в релиз дистрибутива "12.10"?
> в состав каких дистрибутивов оно войдет? В каких случаях может быть смысл
> поменять ядро на это в какой либо установленной и работающей ОС?
> (либо может ли что из элементов "3.6" появиться в апдейтах других
> веток ядра?) Какое количество новых устройств оно стало поддерживать? (и есть
> ли такое старое железо, которое в ней поддерживаться перестало?)
> Когда выйдет следующее и что в нем будет?
> Может ли ядро "3.6" попасть в релиз дистрибутива "12.10"?Ощутимые улучшения в драйверах для Intel и AMD, так что ихмо стоит.
А вобще чукча у нас только писатель:см посты 1.31 & 2.32
Уж не те ли, которые сделаны в сотрудничестве с Валв? В таком случае маст хэв!
> Уж не те ли, которые сделаны в сотрудничестве с Валв? В таком
> случае маст хэв!они самые.
у меня как раз HD4000!
TCP Fast Open - не на руку ли это будет DDOS-ерам? Если устанавливать соединение пачкой tcp пакетов, то в этой же пачке легко можно и ip отправителя подменить и отправить 1000 таких пачек за секунду и все с разными ip.
а сейчас типо айпи адрес поменять нельзя?
> легко можно и ip отправителя подменить и отправить 1000 таких пачекА про syn-flood вы, конечно же, слышите впервые? Это и раньше было можно, знаете ли...
Погуглите про установку соединения и про то, зачем нужны эти 3 этапа. Вкратце: при установке соединения клиент получает от сервера некие данные, на основе которых и формирует ответ. Если ip невалидный, атакующий данные не получит, ответ не отправит, апач потомка не форкнет и атака будет так себе, банальный syn flood, да.
> апач потомка не форкнет и атака будет так себе, банальный syn flood, да.Ну да, ну да. Правда этот тормозной утюг школьники для лулзов заваливают и вполне валидными соединениями. Ну а что, пару тыщ малоактивных соединений можно чуть ли не с телефона по жпрс нынче сделать. А вот как себя почувствует сервак с 2000 форкнутых процессов - вопрос интересный.
гугловцы утверждают, что нет. Затраты на проверку куки TFO дешевле, чем отслеживание SYN. Но как-то не внятно рассказывают, что случиться если флудить будут с валидными куками.
> что случиться если флудить будут с валидными куками.Так фокус в том что валидную куку поди еще подбери. Если ты не тот к кому соединение установили и не перехватываешь пакеты по дороге - на то она и кука чтобы это было сложно.
Вот блин а у меня система с етим ядром не перезагружаеца, да и выключаца тожд не хочет...
Да и KDE перестал UPS видеть...
> и выключаца тожд не хочет...А у меня с ним никаких проблем. Странно. Вы сами компилили?
таже история
http://www.linuxquestions.org/questions/linux-kernel-70/anyo.../
>Вот блин а у меня система с етим ядром не перезагружаеца, да и выключаца тожд не хочет...5-й класс?
Почему до сих пор нет ебилдов?
> Почему до сих пор нет ебилдов?они наверно сначала решили на зеркалах ядро обновить :P
> Почему до сих пор нет ебилдов?Зато я в убунту уже накатил. Trollface.jpg ;D
Ты чё даун? Нах ебилды к ядру??? Ставь ручками. Сам всегда на свою систему ядра ставил ручками через make menuconfig.
> Интеграция патчей для обеспечения размещения разделов подкачки на смонтированных разделах NFS;Своп по сети?! Сначала хотел похихикать. Но вспомнив что сейчас есть гигабитные сети и сервера с большим ОЗУ, понял что задумка неплохая. Особенно для дешевых тонких клиентов.
> сети и сервера с большим ОЗУ, понял что задумка неплохая....вот только то что будет при отпадении сети - вам не понравится категорически.
> ...вот только то что будет при отпадении сети - вам не понравится категорически.а вместе с ним и корень на NFS - так что хуже все равно не будет
Для таких коробок отпадение сети в любом случае смерти подобно
> Для таких коробок отпадение сети в любом случае смерти подобноНу а я виноват что есть желающие совать голову в пасть льва и нахваливать удобство и практичность этого решения?
> Ну а я виноват что есть желающие совать голову в пасть льваСмотря какая то голова будет. Да и львы бывают дресированные.
> Да и львы бывают дресированные.Бывают. Но сообщения в новостях намекают что лучше этого не делать даже с сытым и дрессированным львом.
> Ну а я виноват что есть желающие совать голову в пасть льваотпадение сети это стоп-работа в любой конторе. могут при этом сотрудники играть в пасьянс или нет уже не важно.
> отпадение сети это стоп-работа в любой конторе. могут при этом сотрудники играть
> в пасьянс или нет уже не важно.Только в конторах @#$нувшихся на клаудах и прочем барахле. А ребут роутера обычно никто и не заметит. Но вот если не подчитается своп - это не только заметят. Это будет как серпом по йайцам.
> Только в конторах @#$нувшихся на клаудах и прочем барахле. А ребут роутераотпадение сети это стоп-работа в любой конторе. где в этой фразе вы нашли слово "роутер"?
> обычно никто и не заметит. Но вот если не подчитается свопс роутера?
> отпадение сети это стоп-работа в любой конторе. где в этой фразе вы
> нашли слово "роутер"?Наверное, в сети. И цысковские свичи тоже ребутают при апдейтах фирмвары.
Хотя да, у одептов SVN работа натурально стопается. Потому что без сервака эта гадость шагу ступить не может. Что баг, а не фича.
> с роутера?
Через роутер. Ну или хотя-бы свич. Один фиг для серьезного оборудования обычно производитель апдейты фирмварин делает и иногда наступает нужда перегрузить девайсы. Как-то некузяво если такие вещи вызывают жесткие локапы и паники посторонних систем.
> Наверное, в сети. И цысковские свичи тоже ребутают при апдейтах фирмвары.Речь шла о бездисковых станциях. И о том, что если сеть в конторе лежит, работа стоит в любом случае. А понимаю, что вас задолбали цисковские свитчи и фирмварь их же, к теме разговора это не имеет ни малейшего.
> Хотя да, у одептов SVN работа натурально стопается.
у одептов вжик-вжик по ревижнам скакать? да, стопается. а у вас...
> Один фиг для серьезного оборудования обычно производитель апдейты фирмварин делает и иногда наступает нужда перегрузить девайсы. Как-то некузяво если такие вещи вызывают жесткие локапы и паники посторонних систем.Я правильно понимаю, что у вас серьёзное оборудование и серьёзный производитель постоянно без предупреждения несерьёзных пользователей апдейтит прошивки с ребутом? Не, с таким серьёзным подходом бездисковые станции вам точно не подходит. И да, кажется теперь становится ясным что вам так понравилось в git... Ну с точки зрения одептов SVN это называется "бардак в сети", а порядок - это когда всё стабильно и только по команде. Но зачем их слушать, деревенщину. Сейчас вот серьёзные дядьки ещё пару раз свитч проапдейтят без предупреждения, и не до одептов SVN.
> Потому что без сервака эта гадость шагу ступить не может. Что баг, а не фича.
много что не может ступить шагу без сервака.
>> Интеграция патчей для обеспечения размещения разделов подкачки на смонтированных разделах NFS;
> Своп по сети?! Сначала хотел похихикать. Но вспомнив что сейчас есть гигабитные
> сети и сервера с большим ОЗУ, понял что задумка неплохая. Особенно
> для дешевых тонких клиентов.Задумка не только не плохая но и оправданная для кластерных решений.
Для тонких клиентов или одиночных серверов бессмысленна, и даже вредна.
В кластерах все равно машины с сетевыми хранилищами работают, да и выпадение ноды
не является критичным для сохранности данных.
своп в видеопямять уже есть
> Задумка не только не плохая но и оправданная для кластерных решений.Своп для вычислительных кластеров? Да вы оригинал:)
> Для тонких клиентов или одиночных серверов бессмысленна, и даже вредна.
Прямо противоположно.
>> Задумка не только не плохая но и оправданная для кластерных решений.
> Своп для вычислительных кластеров? Да вы оригинал:)
>> Для тонких клиентов или одиночных серверов бессмысленна, и даже вредна.
> Прямо противоположно.Матмаделирование, которое и 180 GB оперативки захавать может....
не не бывает!
>>> Задумка не только не плохая но и оправданная для кластерных решений.
>> Своп для вычислительных кластеров? Да вы оригинал:)
>>> Для тонких клиентов или одиночных серверов бессмысленна, и даже вредна.
>> Прямо противоположно.
> Матмаделирование, которое и 180 GB оперативки захавать может....
> не не бывает!Для этого уже давно есть что-нибудь на базу Маникур 4CPU по 12 ядер + 512Г оперативки.
>> Задумка не только не плохая но и оправданная для кластерных решений.
> Своп для вычислительных кластеров? Да вы оригинал:)
>> Для тонких клиентов или одиночных серверов бессмысленна, и даже вредна.
> Прямо противоположно.Ну и про то, что в вычислительных кластерах ноды зачастую вообще без дисков и по сети сети грузятся, вы конечно тоже не подозревали?
Сюрприз =)
> Ну и про то, что в вычислительных кластерах ноды зачастую вообще без
> дисков и по сети сети грузятся, вы конечно тоже не подозревали?Как-то сомнительно что там актуален своп по сети.
>> Ну и про то, что в вычислительных кластерах ноды зачастую вообще без
>> дисков и по сети сети грузятся, вы конечно тоже не подозревали?
> Как-то сомнительно что там актуален своп по сети.Ну, если обсчет около месяца длится и объем данных большой, то всякое бывает)
Я же не говорил что своп это хорошо, просто иногда лучше немного в такой своп залезть, но досчитать, чем обломать многонедельную работу.
Опять таки, это всего лишь ихмо.
>>> Ну и про то, что в вычислительных кластерах ноды зачастую вообще без
>>> дисков и по сети сети грузятся, вы конечно тоже не подозревали?
>> Как-то сомнительно что там актуален своп по сети.
> Ну, если обсчет около месяца длится и объем данных большой, то всякое
> бывает)
> Я же не говорил что своп это хорошо, просто иногда лучше немного
> в такой своп залезть, но досчитать, чем обломать многонедельную работу.
> Опять таки, это всего лишь ихмо.Да, это всего-лишь ваше имхо - ничего общего с практикой оно не имеет.
>>> Задумка не только не плохая но и оправданная для кластерных решений.
>> Своп для вычислительных кластеров? Да вы оригинал:)
>>> Для тонких клиентов или одиночных серверов бессмысленна, и даже вредна.
>> Прямо противоположно.
> Ну и про то, что в вычислительных кластерах ноды зачастую вообще без
> дисков и по сети сети грузятся, вы конечно тоже не подозревали?
> Сюрприз =)Не "зачстую", а "как правило".
Своп тут при чём?
GT520 ещё не запилили? Что в ней такого, что Fermi уже поддерживается, а GT520 вешает систему от 3д %)
GTX680 ничего не вешает. Ваш номер очевидно случайно пропустили ;)
Это я знаю ;) Поэтому и интересуюсь. Я читал гдето, что они больше года не могут осилить gt520, хотя вся остальная линейка 5xx воркает %) чозахерь...
> Это я знаю ;) Поэтому и интересуюсь. Я читал гдето, что они
> больше года не могут осилить gt520, хотя вся остальная линейка 5xx
> воркает %) чозахерь...Так nvidia спеки не открывала!
Может они с этой картой железный косяк сделали, да залатали по средствам драйвера...
> GT520 ещё не запилили?Так нвидии этот вопрос задавайте. Где спеки от вендора? Нету? Ну а реверс-инжинирингом работает уж как получится, т.к. все краевые случаи и неочевидности при реверсинге очень сложно обнаружить.
отлично, осталось подождать когда статистику обновятvidarholen.net/contents/wordcount/
Какое-то скупое сообщение про DRM под карточки Radeon. Они бы нормальную test-реализацию сделали, а то уже какой месяц я фигею от вылета X-ов с ошибкой в drm. Жаль, что не могу с бука выдрать эту карточку и поставить стабильноподдерживаему как mesa, так и ядром с дровами x86f-*
> Какое-то скупое сообщение про DRM под карточки Radeon. Они бы нормальную test-реализацию сделали,Вы так говорите как будто все радеоны виснут. Как обладатель радеона я ответственно заявляю что это не так.
> а то уже какой месяц я фигею от вылета X-ов с ошибкой в drm.
А у вас распоследняя версия ядра и драйверов? Если да и вы уверены что это именно ошибка в ядре - тогда попробуйте багрепорт накатать.