Подготовка дисков и разделов

Итак после первого впечатления от знакомства с сервачком приступил к установке системы.
Предустановлена была няшная кубунта, и, в последний раз вглянув на красивые сглаженные окошки со всплывающими свистелками и перделками, я ребутнулся чтобы остаться в суровом консольном мире навсегда.
Как уже было сказано, fake-RAID от интела оказался сплошным разочарованием, так что я просто его отключил, перевев контроллер дисков в режим Advanced Host Controller Interface (AHCI). Отличается от стандартного IDE режима наличием дополнительных фич, таких как hot swap дисков и Native Command Queuing (NCQ). Последнее теоретически должно придать перфомансу дискам. Более подробно про IDE vs AHCI здеся.
В итоге я получил 4 отдельных диска на этапе установки.
Для установки использовал лайв сиди Ubuntu 10.04 server edition. К слову, 10.04 это Long Term Support (LTS) релиз, который для серверного варианта поддерживается 5 лет. Юху!
Установка в целом прошла гладко, если не считать крайней конфузный интерфейс для настройки софтового RAID с помощью mdraid, предлагаемого по-умолчанию визардом. Очень неудобно и результаты тех или иных действий порой совершенно нелогичны. Это привело к тому что я отбросил первоначальную идею навернуть поверх всего этого бутерброда еще и Logical Volume Manager (LVM). На фриноде порекомендовали LVM как средство постоянного аптайма сервака при отсутствии каких-либо заметных ухудшений производительности. Ну да хрен с ним, еще будет возможность переставить.
Лучшее, как говорится. враг хорошего и после мучительных стенаний относительно разбиения/собирания дисков в рейды я пришел к следующей суровейшей системе, которая конечно же будет работать хуже самой простой.

Первые 4 ГБ Дисков 1 и 2 в RAID0 - R0
Следующие 90 ГБ Дисков 1 и 2 в RAID1  - R1.1
Оставшиеся 900 ГБ Дисков 1 и 2 в RAID1 -  R1.2
Диски 3 и 4 полностью в RAID1 - R1.3
Рейды R1.2 и R1.3 в RAID0  - R10

На выходе получаем R0 - 8 ГБ, R1.1 - 90 ГБ, R10 - 1.9 ТБ
На R0 организовываю swap
R1.1 разбиваю на два партишна: 30 ГБ ext3 под / , 60 ГБ ext3 под /srv
На R10 ставлю xfs, замаунченый на /var

Вот такой вот винегрет, хз что из этого выйдет, будем тестировать.
К слову, создать файловую систему на R1.1  на этапе установки я смог лишь одну, ту которая под рут. Попытка создать вторую на 60 ГБ под /srv приводила лишь к страшному красному окну с надписью "Failed!". Пришлось ручками уже на рабочей системе допиливать. Использовал при этом устройства /dev/md* которые были созданы mdraid-ом.

# /dev/md3 это мой R1.1, на котором разделы для / и /srv
sudo fdisk /dev/md3

Command (m for help):  n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4):  2
...
# далее дефолтные значения начала и конца, чтобы заполнить все оставшееся место
Command (m for help): p
    Device Boot      Start         End      Blocks   Id  System
/dev/md3p1   *           1        3648    29295616   83  Linux
/dev/md3p2            3648       11671    64450667+  83  Linux
Command (m for help): w

После того как раздел был создан и изменения записаны осталось только создать файловую систему и замаунтить ее.

# без -j создалась бы ext2, а так будет ext3
sudo mke2fs -j /dev/md3p2

#смотрим в /etc/fstab  и срем кирпичом от UUID
cat /etc/fstab
#              
proc            /proc           proc    nodev,noexec,nosuid 0       0

# / was on /dev/md3p1 during installation
UUID=e6f5000d-5501-48b2-81bf-8389e6757b5c /               ext3    errors=remount-ro 0       1
...

Небольшое отступление. Почему вместо привычных /dev/sda1 в /etc/fstab мы иногда видим такие вот страшные UUID. Смысл здесь в том, что /dev/sdXX - привязка к слоту материнки. Если у вас скажем два диска в слотах 1 и 2,  и вы скажем приобрели новый диск и вам вдруг позарез нужно вставить этот новый диск между двумя старыми, то старые разместите в слотах 1 и 3, а новый в 2. В итоге получим несоответствие в системе, которая ожидает один из старых дисков в слоте 2, а получает там новый диск. Примдется бутаться как-нить по особому и править fstab. При использовании же UUID ничего править не придется, все заработает сразу, так как UUID раздела не зависит от того, где стоит диск. Как видно, ситуация в крайней степени сферическая, но чтобы построить новое, сохранить лучшее я решил таки замапить и свой раздел через UUID:

# узнаем UUID раздельчика
sudo dumpe2fs /dev/md3p2 | grep -i uuid
Filesystem UUID:          36fbe572-4678-47be-a477-4d28d4a6ae07

sudo vim /etc/fstab
# и добавляем строчки
# /srv was on /dev/md3p2
UUID=36fbe572-4678-47be-a477-4d28d4a6ae07 /srv            ext3    defaults        0       2

Здесь defaults - маунт флаги (точнее их отсутствие), 0 - не производить никаких бекап манипуляций с разделом, 2 - проверка ошибок файловой системы осуществлять позже чем у рута. Сохраняем.
Так как система теперь использует UUID вместо устройства, следует самим помнить что скрывается под тем или иным UUID в fstab, для этого я и добавил коммент по аналогии с теми, которая умненькая убунточка сама сгенерила. Однако это всего лишь для удобства. Если же устройство забылось то всегда можно узнать его по данному UUID:

ls -l /dev/disk/by-uuid/36fbe572-4678-47be-a477-4d28d4a6ae07
lrwxrwxrwx 1 root root 11 2011-02-24 11:06 /dev/disk/by-uuid/36fbe572-4678-47be-a477-4d28d4a6ae07 -> ../../md3p2

После прописанного маунта остается либо ребутнуться либо вручную замаунтить наш раздел:

sudo mount /dev/md3p2 /srv

После этого диски были готовы к работе. Ура!