Перенос установленной ОС Linux на программный RAID.
Предположим, у нас есть сервер с установленной на нём операционной системой Linux. Система установлена на единственном диске и нам нужно сделать отказоустойчивую конфигурацию, застраховавшись от выхода этого диска из строя. Для этого мы добавляем к серверу второй диск и хотим создать RAID1 («зеркало»), т. е. конфигурацию, при которой все данные с первого диска дублируются на второй и при выходе из строя одного из дисков система работает на оставшемся. Ситуация осложняется тем, что на нашем сервере отсутствует аппаратный RAID-контроллер, поэтому RAID будем строить программный (софтовый).
Все описываемые ниже действия проведены на операционной системе Ubuntu 12.04. Для других операционных систем семейства Linux команды могут несколько отличаться от приведённых, но общие принципы построения программных RAID-массивов останутся неизменными. Мы ограничимся рассмотрением RAID1, но путём небольшой модификации данную инструкцию можно применять и для массивов других типов, например, RAID5, RAID6, RAID10 и т. п. Мы предполагаем, что объём нового (добавляемого) диска не меньше чем у старого (работающего). (На самом деле можно и меньше – см. примечание 5.) Также будем предполагать, что сервер можно на некоторое время остановить и несколько раз перезагрузить.
Кольцевой буфер с несколькими потребителями
В процессе разработки программы MultiCopy возникла одна задача, решение которой в виде отдельного класса мне найти не удалось. Это – задача использования кольцевого буфера несколькими потребителями. Смысл «многоцелевого» копирования, которое реализует программа MultiCopy, состоит в том, чтобы записывать в несколько файлов одни и те же данные, то есть каждая ячейка кольцевого буфера должна быть записана во все файлы и только затем помечена как свободная. Иными словами, ячейка буфера помечается как свободная только после того, как её прочитают все потребители.
Приводимый обычно пример использования кольцевого буфера и семафоров ограничен тем, что в нём присутствует один поток-производитель и только один поток-потребитель. Такая реализация не подходит, поскольку ячейка будет освобождаться первым прочитавшим её потребителем. Однако, было необходимо, чтобы блок был прочитан всеми потребителями до перезаписи производителем. Решение этой задачи привело к созданию класса TSynchronizer.