Томас Глейкснер (Thomas Gleixner), основной разработчик и мейнтейнер RT-ветки ядра Linux, сообщил о выпуске тестовой верcии набора патчей с реализацией режима реального времени (Realtime-Preempt", PREEMPT_RT или "-rt") для ядра Linux 3.0. Ядро "-rt" с реализацией жёсткого режима реального времени используется в real-time редакциях промышленных Linux дистрибутивов MontaVista, Red Hat и Novell. Это первое крупное обновление RT-Linux за последние несколько лет, которое знаменует собой уход от ядра версии 2.6.33, которое было использовано в качестве базы для RT-ветки несколько лет подряд.
В письме, отправленном в список рассылки Linux-ядра, Томас Глейкснер отмечает существенное отличие новой версии патчей от предыдущих. Логика работы многих подсистем была кардинально переработана, код стал намного чище и проще для анализа, общий размер патчей сократился более чем в два раза. Теперь код затрагивает гораздо меньше подсистем и структур данных ядра, что, по мнению автора, позволит ускорить процесс его включения в основную ветку. 223 подготовленных в рамках проекта патча, затрагивающих 374 файла разбиты на 4 группы, из которых одна группа устраняет недоработки уже находящихся в ядре подсистем, одна группа уже отправлена для включения в состав основного ядра, одна признана готовой для отправки заявки на включение в состав ядра и одна требует доработки и проверки. Для сравнения, для ветки 2.6.33 было подготовлено 462 патча, затрагивающих 690 файлов.
Ядро с наложенными патчами было протестировано на платформах x86 и x86_64, а также на ARM, MIPS и PowerPC и, по словам Thomas Gleixner оказалось "удивительно стабильным" (amazinlgy stable). Событие знаменательно тем, что это первый случай когда RT-патчи адаптированы для последней актуальной версии Linux-ядра, ранее выпуск патчей существенно отставал, что было связано с большой трудоёмкостью процесса портирования и тестирования.
Дополнение: доступен набор патчей 3.0-rt1 для финальной версии ядра
ЗЫЖ я не знаю у кого как, но у меня регистрация не нужна (если вы не хотите сами писать и заливать файлы), все внутренние ссылки доступны без регистрации.
А это была ссылка на административный раздел, который нужен для тестирования разных роботов.
]]>не требует ваще-то...
http://forum.drbatty.ru/viewtopic.php?f … 152#p14152
4.2. Ваша ссылка ведёт во "вход", и рисует два окошка ввода. логина и пароля.
разлогиньтесь и кликните на свою ссылку.
Сцылко требует регистрации. Можно для Ъ - что там?
не требует ваще-то...http://forum.drbatty.ru/
для Ъ
Разработчики проекта NEXT3, в рамках которого уже несколько лет развивается неофициальная реализация поддержки мгновенных снимков состояния файловой системы Ext3 (снапшотов), представили первый выпуск набора патчей ext4-snapshots, обеспечивающих работу снапшотов в файловой системе Ext4.
Вопрос об интеграции представленного набора патчей в Linux-ядро пока не решен. Набор состоит из 36 патчей и интегрируется с Ext4 через систему стандартных хуков. Предусмотрена возможность монтирования разделов с отключением поддержки снапшотов, в этом случае код никак себя не проявляет и ФС Ext4 функционирует как раньше. В качестве причины развития проекта указано желание интегрировать возможность работы со снапшотами в уже зарекомендовавшую себя и повсеместно используемую ФС Ext4, вместо использования экспериментальной ФС Btrfs или системы dm_multisnap.
Разработка проекта ведется компанией CTERA Networks, которая использует код проекта NEXT3 в своих NAS-хранилищах и гибридных системах хранения данных. Несмотря на то, что патчи уже достаточно хорошо протестированы и отлажены в недрах компании CTERA, для интеграции их в ядро требуется более широкомасштабное тестирование и оценка их влияния на производительность. По заявлению разработчиков проекта патчи готовы к интеграции в состав Linux-ядра. Так как окно по принятию патчей для ядра 3.0 уже закрыто, а следующее будет только в августе, у энтузиастов есть несколько месяцев на проведение дополнительного тестирования.
В отличии от снапшотов на базе LVM, система снапшотов на уровне файловой системы обладает следующими преимуществами:
Снапшоты не требуют предварительного резервирования места, что позволяет гибко управлять доступным свободным пространством. Снапшоты Next3 являются компактными и требуют дополнительного места только для хранения изменений;
Близкая к линейной масштабируемость - даже при огромном количестве снапшотов скорость остается на уровне, близком к Ext4;
Поддержка инкрементальных снапшотов, доступных только на чтение (создаем снапшот: "snapshot.ext4dev take Monday", монтируем его: "snapshot.ext4dev mount Monday", удаляем: "snapshot.ext4dev delete Monday");
Снапшоты создаются и удаляются практически мгновенно. Сразу же после удаления снапшота занятое им пространство автоматически освобождается;
Полная прямая и обратная совместимость с Ext4. Миграция с Ext4 на вариант с поддержкой снапшотов и обратно выполняется буквально в три команды ("umount /dev/xxx; snapshot.ext4dev on /dev/xxx; mound -t ext4dev /dev/xxx").
Инструкцию по установке можно найти здесь (вместо модуля next3 следует указать ext4dev, а вместо скрипта next3 - snapshot.ext4dev). Тестовые патчи подготовлены для Linux-ядра 2.6.38 и протестированы в дистрибутивах Ubuntu 11.04 и Fedora 15. Загрузить предкомпилированную версию для систем x86_64 можно здесь.
снапшоты есть и в EXT4
Сцылко требует регистрации. Можно для Ъ - что там? 
Более того, я уверен в этом. Поэтому и пишу — «субъективно».
"субъективно" это по другому:
1) забиваем диск нулями, ставим ось на ФС1 - смотрим.
2) забиваем диск нулями, ставим ось на ФС2 - смотрим.
если кажется что в случае 2 быстрее - значит субъективно ФС2 лучше. но для объективного сравнения необходимо ещё и ставить разные оси и по разному. Может в убунте прописан параметр №772 == 19834, и ФС2 с таким параметром работает лучше. Но если поставить мандриву где параметр №772 == 17, то ФС1 порвёт ФС2 в клочья. Такие дела.
По большому счёту, одна из возможностей btrfs — создание снапшотов — перевешивает для меня и скорость загрузки, и работу с файлами...
скорость загрузки
не нужно.
и работу с файлами...
а мне от файловой системы нужно именно работу с файлами...
UPD: ссылка исправлена.
]]>Главное - выключать всегда правильно, ибо "провоцировать" fsck лучше не стоит.
Только в порядке эксперимента, и у меня был рабочий backup системы.
]]>ы не умали о том, что поставив скажем EXT3, с нуля, скорость тоже возрастёт? Причём значительно.
Более того, я уверен в этом. Поэтому и пишу — «субъективно».
По большому счёту, одна из возможностей btrfs — создание снапшотов — перевешивает для меня и скорость загрузки, и работу с файлами...
]]>Установил, скорость загрузки и запуска приложений возросла.
вы не умали о том, что поставив скажем EXT3, с нуля, скорость тоже возрастёт? Причём значительно.
]]>Lupo Alberto, дык у него вроде unstable disk format?
Battle Coder, у него unstable random recovery via fsck-current.
Это я сильно сказал — «тестирую» wink
Установил, скорость загрузки и запуска приложений возросла. Специально не измерял, сужу субъективно.
Несколько раз специально делал «мягкий» Reset «магическими» клавишами, один раз — «жёсткий», вынув батарею.
Данные все на месте. Очень нравится система снапшотов — проще отката к предыдущему состоянию я ещё не видел. Если раздел не корневой, даже перегружаться не надо. Возможно, и с корневым как-то можно обойтись без перезагрузки.
Единственный заметный для меня «минус» — своеобразный учёт дискового пространства в этой файловой системе sad
Возможно, «баги» себя ещё проявят, но те пару недель, которые я использую btrfs, я их не вижу.
]]>