Архив метки: Kernel

Как пользоваться утилитой dmesg в Linux

Когда система запущена и активна, ядро Linux записывает сообщения разного рода в кольцевой буфер ядра. В этих сообщениях содержатся данные относительно функционирования операционной системы. Так как буфер ядра имеет ограниченный объем памяти, он периодически переполняется информацией. Как только лимит памяти исчерпывается, система начинает перезаписывать старые записи журналов.

Для управления кольцевым буфером ядра разработана утилита dmesg. С её помощью пользователь может изучить загрузочные сообщения ядра, а также заняться устранением текущих проблем, возникающих в процессе работы определенного оборудования. Как и у любой другой программы, у данной утилиты есть определенные опции и причины применения. Читать

KVM / Создание снимков виртуальных машин

Qemu-KVM поддерживает создание снимков виртуальных машин. От суперпользователя заходим в virsh и выполняем следующую команду:

virsh # snapshot-create-as name

name — это имя виртуальной машины.

После того, как снимок виртуальной машины будет сделан, резервные копии файлов конфигураций будут лежать в директории /var/lib/libvirt/qemu/snapshot/.

Просмотреть снимки можно следующей командой:

virsh # snapshot-list name

Name Creation Time State
— 2340593244 2015-06-18 17:34:04 +0200 running
2340594479 2015-06-18 17:54:39 +0200 running

Восстановить из snapshot можно так:

virsh # snapshot-revert name 2340593244

Удалить не нужный снимок можно так:

virsh # snapshot-delete name 2340593244

Автор: AugustuS Karro

Ядро Linux за 10 минут (обзор)

 

Это конспект доклада для семинара, проведённого нашей LUG совместно с университетом.

 

У меня, натурально, было 10 минут, поэтому изложение — галопом по европам, многое упрощено, многое упущено.

 

Немного истории

Относительно подробную историю создания ядра Linux можно найти в известной книге Линуса Торвальдса «Just for fun». Нас из неё интересуют следующие факты:

  • Ядро создал в 1991 году студент университета Хельсинки Линус Торвальдс;
  • В качестве платформы он использовал ОС Minix, написанную его преподавателем Эндрю Таненбаумом, запущенную на персональном компьютере с процессором Intel 80386;
  • В качестве примера для подражания он использовал ОС семейства Unix, а в качестве путеводителя — сначала стандарт POSIX, а затем просто исходные коды программ из комплекта GNU (bash, gcc и пр).

Эти факты в значительной мере определили пути развития ядра в дальнейшем, их следствия заметны и в современном ядре.

В частности, известно, что Unix-системы в своё время разделились на два лагеря: потомки UNIX System V Release 4 (семейство SVR4) против потомков Berkley Software Distribution v4.2 (BSD4.2). Linux по большей части принадлежит к первому семейству, но заимствует некоторые существенные идеи из второго.

Ядро в цифрах

  • Около 30 тыс. файлов
  • Около 8 млн. строк кода (не считая комментариев)
  • Репозиторий занимает около 1 Гб
  • linux-2.6.33.tar.bz2: 63 Mb
  • patch-2.6.33.bz2: 10Mb, около 1.7 млн изменённых строк
  • Около 6000 человек, чей код есть в ядре

Об архитектуре ядра

Все (или почти все) процессоры, которыми когда-либо интересовались производители Unix-подобных ОС, имеют аппаратную поддержку разделения привелегий. Один код может всё (в т.ч. общаться напрямую с оборудованием), другой — почти ничего. Традиционно говорят о «режиме ядра» (kernel land) и «режиме пользователя» (user land). Различные архитектуры ядер ОС различаются прежде всего подходом к ответу на вопрос: какие части кода ОС должны выполняться в kernel land, а какие — в user land? Дело в том, что у подавляющего большинства процессоров переключение между двумя режимами занимает существенное время. Выделяют следующие подходы:

  • Традиционный: монолитное ядро. Весь код ядра компилируется в один большой бинарный файл. Всё ядро исполняется в режиме ядра;
  • Противоположный, новаторский: микроядро. В режиме ядра выполняются только самые необходимые части, всё остальное — в режиме пользователя;
  • В традиционном подходе позже появился вариант: модульное ядро. Всё исполняется в режиме ядра, но при этом ядро компилируется в виде одного большого бинарного файла и кучки мелких модулей, которые могут загружаться и выгружаться по необходимости;
  • И, конечно, всевозможные варианты гибридных архитектур.

Ядро Linux начиналось как монолитное (глядя на существовавшие тогда Unix-ы). Современное Linux-ядро модульное. По сравнению с микроядром монолитное (или модульное) ядро обеспечивает существенно бо́льшую производительность, но предъявляет существенно более жёсткие требования к качеству кода различных компонентов. Так, в системе с микроядром «рухнувший» драйвер ФС будет перезапущен без ущерба для работы системы; рухнувший драйвер ФС в монолитном ядре — это Kernel panic и останов системы.

Подсистемы ядра Linux

Существует довольно широко известная диаграмма, изображающая основные подсистемы ядра Linux и их взаимодействие. Вот она:

: linux-kernel-big.png

Собственно, в настоящий момент видно только, что частей много и их взаимосвязи очень сложные. Поэтому мы будем рассматривать упрощённую схему:

: linux-kernel-simple.png

Системные вызовы

Уровень системных вызовов — это наиболее близкая к прикладному программисту часть ядра Linux. Системные вызовы предоставляют интерфейс, используемый прикладными программами — это API ядра. Большинство системных вызовов Linux взяты из стандарта POSIX, однако есть и специфичные для Linux системные вызовы.

Здесь стоит отметить некоторую разницу в подходе к проектированию API ядра в Unix-системах с одной стороны и в Windows[NT] и других идеологических потомках VMS с другой. Дизайнеры Unix предпочитают предоставит

Файловая система Btrfs

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

Введение

Речь пойдёт о файловой системе нового поколения. Традиционно ФС играла значительную роль в организации Unix-систем. И во многом именно свойствами ФС определялись свойства той или иной реализации Unix.

Файловая система должна хранить файлы и обеспечивать доступ к ним. При этом к ней предъявляется большое количество требований, зачастую взаимоисключающих: поддержка файлов любого размера, высокая производительность операций ввода/вывода, масштабируемость и т.д. Давно стало ясно, что ни одна файловая система не может быть одинаково эффективна во всех случаях. Поэтому все современные реализации Unix поддерживают работу с несколькими типами ФС одновременно. Есть такое выражение: «Linux — это Unix сегодня», и ядро Linux поддерживает свыше 50 (!) типов ФС.

ФС нового поколения

В 2005-м году компания Sun Microsystems представила файловую систему ZFS, которая стала прорывом в области файловых систем. Из-за лицензионной политики Sun ZFS не может быть включена в ядро Linux. Однако в 2007-м году началась разработка файловой системы нового поколения для Linux — Btrfs. Разработку оплачивает компания Oracle, однако код выпускается под лицензией GNU GPL и входит в ядро Linux начиная с релиза 2.6.29, вышедшего на этой неделе.

Приведу фрагмент интервью Chris Mason — основного разработчика Btrfs:

  • Опишите Btrfs своими словами.

  • Btrfs — это новая файловая система, выпускаемая под GPL, которая разрабатывается с учётом масштабируемости на очень большие объёмы носителей. Масштабируемость означает не только возможность адресовать блоки носителя, но также возможность работать с повреждениями данных и метаданных. Это означает наличие инструментов для проверки и восстановления файловой системы без отмонтирования, и интегрированную проверку контрольных сумм, чтобы определять ошибки.

  • Является ли Btrfs наследницей какой-нибудь другой ФС?

  • Да, всех их 🙂 Здесь много идей из ReiserFS, отложенное размещение и другие идеи из XFS. ZFS популяризовала идею, что подсчёт контрольных сумм данных может быть быстрым, и что управление логическими томами может быть лучше. Идеи по реализации управления томами пришли из AdvFS.

Основные возможности Btrfs

Итак, основные возможности, которые будут в Btrfs:

  • Поддержка доступных на запись снапшотов (аналог клонов ZFS). Кроме того, здесь можно создавать снапшоты снапшотов.

  • Поддержка субтомов — множественных именованных корней в одной файловой системе с общим пулом хранения.

  • Поддержка сложных многодисковых конфигураций — RAID уровней 0, 1, 5, 6 и 10, а также реализация различных политик избыточности на уровне объектов ФС — то есть возможно назначить, к примеру, зеркалирование для какого-либо каталога или файла.

  • Copy-on-write (CoW) журналирование.

  • Контроль целостности блоков данных и метаданных с помощью контрольных сумм.

  • Зеркалирование метаданных даже в однодисковой конфигурации.

  • Полностью распределенное блокирование.

  • Поддержка ACL.

  • Защита от потери данных.

  • Выбор хэш-алгоритма.

  • Поддержка NFS.

  • Флаги совместимости, необходимые для изменения дискового формата в новых версиях btrfs с сохранением совместимости со старыми.

  • Резервные копии суперблока, по крайней мере — по одной на устройство.

  • Скоростные приоритеты для дисков.

  • Гибридные пулы. btrfs старается перемещать наиболее используемые данные на самое быстрое устройство, вытесняя с него «залежавшиеся» блоки. Эта политика хорошо согласуется с появившейся недавно моделью использования SSD (Solid State Drive).

  • Балансировка данных между устройствами в btrfs возможна сразу после добавления диска к пулу, отдельной командой — а не только постепенно, в процессе использования (как это реализовано в ZFS).

  • Диски для горячей замены, поддержка кот